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Abstract 


Many  computational  effects,  such  as  exceptions,  state,  or  nondeterminism, 
can  be  conveniently  specified  in  terms  of  monads.  We  investigate  a  technique 
for  uniformly  adding  arbitrary  such  effects  to  ML-like  languages,  without 
requiring  any  structural  changes  to  the  programs  themselves.  Instead,  we  use 
inonadic  reflection,  a  new  language  construct  for  explicitly  converting  back 
and  forth  between  representations  of  effects  as  behavior  and  as  data. 

Using  monadic  reflection  to  characterize  concisely  all  effects  expressible  with 
a  given  monad,  we  can  give  a  precise  meaning  to  the  notion  of  simulating  one 
effect  by  another,  more  general  one.  We  isolate  a  simple  condition  allowing 
such  a  simulation,  and  in  particular  show  that  any  monadic  effect  can  be 
simulated  by  a  continuation  monad.  In  other  words,  under  relatively  mild 
assumptions  on  the  base  language  (allowing  formation  of  a  suitably  large 
answer  type),  control  becomes  a  universal  effect. 

Concluding  the  development,  we  show  that  this  universal  effect  can  itself 
be  explicitly  implemented  in  terms  of  only  standard  first-class  continuations 
(call/cc)  and  a  piece  of  global  state.  This  means  that  we  can  specify  an  ef¬ 
fect  such  as  nondeterminism  abstractly,  in  terms  of  result  lists,  then  directly 
obtain  from  this  description  a  nondeterministic-choice  operator  performing 
imperatively-implemented  backtracking.  We  include  a  full  realization  of  the 
general  construction  in  Standard  ML  of  New  Jersey,  and  give  several  pro¬ 
gramming  examples. 
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Chapter  1 
Introduction 


In  this  chapter,  we  cover  some  general  background  and  motivation  for  the  work  de¬ 
scribed  in  this  document.  After  a  brief  discussion  of  two  popular  conceptual  models  for 
programming  with  computational  effects,  we  introduce  a  new  approach  that  in  many 
ways  combines  the  best  aspects  of  both.  We  give  an  informal  overview  of  this  approach 
and  sketch  the  concrete  results  obtained  in  the  following  chapters. 

1.1  Effects  in  functional  languages 

An  important  topic  in  the  field  of  programming  language  semantics  is  the  study  of  compu¬ 
tational  effects.  Informally,  an  effect  is  any  deviation  from  the  intuitive  characterization 
of  a  program  fragment  as  representing  a  simple  function  from  inputs  to  outputs.  Ex¬ 
amples  are  numerous,  including  such  familiar  concepts  as  partiality,  exceptions,  state, 
computational  complexity,  I/O,  nondeterminism,  and  concurrency. 

The  treatment  of  effects  is  particularly  interesting  in  the  context  of  modern  functional 
programming  languages,  such  as  Standard  ML  or  Haskell.  Such  languages  have  relatively 
simple  and  tractable  mathematical  descriptions,  amenable  to  a  formal  analysis.  In  fact, 
their  basic  model  of  computation  is  precisely  the  definition  and  evaluation  of  functions, 
as  opposed  to  sequential  execution  of  program  instructions. 

But  even  though  most  aspects  of  functional  programming  can  indeed  be  usefully  cap¬ 
tured  with  this  simple  declarative  model,  the  natural  formulation  of  many  non-trivial  pro¬ 
gramming  tasks  still  tends  to  involve  occasional  uses  of  “imperative”  concepts  -  whether 
for  convenience  in  expressing  an  algorithm,  or  for  interaction  with  the  outside  world. 

The  challenge  to  the  semanticist  is  thus  to  admit  the  possibility  of  effects,  while 
retaining  as  many  as  possible  of  the  appealing  properties  of  functional  programming.  This 
problem,  of  course,  is  not  new;  but  somewhat  surprisingly,  two  distinct  schools  of  thought 
have  evolved  on  how  best  to  proceed,  exemplified  by  the  treatment  of  effects  in  “purely 
functional”  languages,  such  as  Miranda  or  Haskell,  versus  “algorithmic  functional”  ones, 
such  as  Scheme  or  ML. 

The  remainder  of  this  section  briefly  presents  and  contrasts  these  two  approaches, 
then  introduces  the  basic  thesis  underlying  this  dissertation:  that  we  can  integrate  key 
ideas  from  each  framework  to  obtain  a  model  of  specifying  and  using  effects  that  combines 
the  best  of  both  worlds. 
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1.1.1  “Effects  as  data” 

When  the  basic  ideas  of  denotational  semantics  were  originally  proposed,  a  significant 
challenge  was  to  demonstrate  that  a  very  abstract  mathematical  model  of  computation 
based  on  “pure”  functions  could  adequately  model  some  apparently  very  non-functional 
but  (at  least  at  that  time)  important  constructs  in  existing  programming  languages.  Per¬ 
haps  the  most  striking  example  of  this  was  the  use  of  continuation  functions  for  modeling 
unstructured  control  constructs  (gotos)  [SW74,  Rey93];  simpler  techniques  sufficed  for 
concepts  such  as  state  or  exceptions. 

There  is  a  close  similarity  between  the  metalanguage  of  denotational  semantics  (a  con¬ 
cise  notation  for  specifying  continuous  functions  between  domains)  and  actual  functional 
programming  languages.  This  has  the  fortunate  consequence  that  often  an  appropriately 
expressed  denotational  definition  can  be  directly  executed  to  get  an  interpreter  for  the 
defined  language  [Rey72],  And  in  fact,  many  of  the  techniques  pioneered  in  denotational 
semantics  were  quickly  adopted  for  functional  programs  that  were  not  in  any  reasonable 
sense  language  processors. 

Specifically,  the  denotational  representation  of  almost  every  computational  effect  leads 
to  a  characteristic  pattern  or  style  in  functional  programs  using  that  effect.  For  example, 
a  global  store  can  be  modeled  functionally  by  passing  an  additional  store  argument  to 
every  function,  together  with  returning  from  each  function  the  possibly  updated  store; 
the  resulting  specification  is  commonly  said  to  be  expressed  in  state-passing  style. 

Similarly,  exceptions  can  be  modeled  by  tagging  every  function  return  value  as  either 
“normal”  or  “exceptional”;  the  caller  of  a  function  must  then  explicitly  check  for  and 
propagate  exceptions  ( exception-passing  style).  And,  perhaps  best-known,  continuation¬ 
passing  style  (CPS)  passes  to  every  function  an  explicit  representation  of  the  remainder 
of  the  computation,  to  be  invoked  on  the  result  of  that  function  [Rey72,  Fis72,  Plo75]. 

While  these  techniques  for  modeling  computational  effects  all  share  a  similar  feel,  they 
do  differ  substantially  in  the  details.  It  was  therefore  a  remarkable  observation  by  Moggi 
that  they  could  each  be  seen  as  a  particular  instance  of  a  generic  schema,  parameterized 
by  a  monad ,  a  simple  concept  from  category  theory  [Mog89].  This  meant  that  much  of 
the  theory  of  computational  effects  could  be  derived  abstractly,  without  reference  to  any 
specific  notion  of  effect. 

Again,  it  did  not  take  long  for  this  idea  to  migrate  from  mathematical  semantics 
to  mainstream  functional  programming.  Work  by  Wadler  and  others  [Wad90,  Wad92b, 
PW93]  established  monadic  style  as  a  practical  technique  for  structuring  purely  functional 
programs  in  a  way  that  could  reasonably  conveniently  express  both  program-internal 
effects  (exceptions,  state,  etc.)  and  external  ones  (foreign  function  interfaces  and  monadic 
I/O). 

The  benefits  of  a  denotational  specification  of  an  effect  are  substantial:  we  get  a 
concise  yet  very  precise  characterization  of  how  a  program  fragment  can  behave.  For 
example,  in  a  language  with  exceptions  and  non-termination  as  the  only  effects,  the 
meaning  of  an  integer-returning  computation  could  be  a  meta-language  value  of  type 

©  -Y  where  X  is  some  fixed  domain  of  exception  names. 

This  immediately  tells  us  that  evaluation  of  an  expression  can  have  only  three  possible 
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outcomes:  it  either  returns  a  number,  raises  an  exception,  or  diverges.  Thus,  for  example, 
a  simple  case  analysis  suffices  to  formally  show  that  evaluating  an  expression  twice  is 
equivalent  to  evaluating  it  only  once  and  duplicating  the  result  -  even  if  we  interpose  an 
arbitrary  other  computation  between  the  two  evaluations. 

Analogous  considerations  apply  to  a  purely  functional  program  in  exception-passing 
style:  we  can  use  standard  reasoning  principles  for  sum  types  to  deduce  properties  of  pro¬ 
grams  with  exception-effects,  again  validating  program  transformations  such  as  common- 
subexpression  elimination. 

On  the  other  hand,  the  purely-functional  approach  is  not  without  problems,  which 
become  particularly  evident  at  larger  scales.  One  such  disadvantage  is  that  programming 
with  effects  turns  into  an  all-or-nothing  choice:  to  add  even  the  most  innocuous  effect, 
such  as  debugging  output  or  a  “gensym”  facility  for  generating  unique  names,  we  may 
have  to  rewrite  substantial  parts  of  the  program  in  effect-passing  style. 

Monads  alleviate  this  inconvenience  somewhat,  by  allowing  the  program  to  be  struc¬ 
tured  uniformly,  independently  of  what  effects  will  eventually  be  present.  Still,  we  need 
to  explicitly  re-express  the  underlying  functional  program  in  monadic  style  -  sometimes 
after  the  fact,  duplicating  effort,  and  sometimes  preemptively,  in  anticipation  of  possibly 
having  to  add  effects  in  the  future. 

Of  course,  since  the  conversion  into  monadic  style  is  easily  mechanizable,  we  can 
always  express  programs  in  a  more  concise  notation,  and  have  them  automatically  ex¬ 
panded  into  monadic  style  -  either  explicitly  as  a  source  transformation,  or  implicitly  by 
an  interpreter.  But  such  an  approach  is  not  without  problems  either:  by  interposing  a 
translation  phase  for  expanding  monadic  effects  into  their  denotations,  we  are  effectively 
defining  an  entirely  new  programming  language. 

And  for  writing  any  non-trivial  programs  in  this  new  language,  we  will  want  all  the 
conveniences  commonly  provided  by  a  language  environment:  pattern-matching  function 
definitions,  a  static  type  system  (giving  meaningful  error  messages),  a  module  system,  a 
standard  library,  etc.  Thus,  the  practical  effort  involved  may  be  much  larger  than  what 
might  be  expected  from  only  looking  at  the  core  translation  equations. 

A  related,  but  logically  distinct,  problem  is  that  monadic-style  definitions  impose 
a  substantial  overhead  on  execution,  whether  implemented  interpretively  or  compiled. 
Even  if  effects  are  rare  (which  is  one  of  the  tenets  of  functional  programming),  the 
infrastructure  required  to  support  an  occasional  imperative  construct  imposes  a  uniform 
burden  on  the  entire  evaluation  process. 

For  example,  for  exception-passing  style,  the  specification  demands  that  after  every 
subcomputation  that  may  raise  an  exception,  we  have  to  check  for  this  possibility  and 
either  proceed  normally,  or  propagate  the  exception  to  the  rest  of  the  computation. 
A  simple  realization  of  exception-passing  could  thus  spend  a  large  fraction  of  its  time 
checking  for  conditions  that  only  occur  very  rarely.  A  more  sophisticated  implementation, 
especially  a  translation-based  one,  may  be  able  to  eliminate  some  of  those  checks,  but 
in  general  calls  to  “unknown”  functions  (passed  as  parameters  or  separately  compiled) 
have  to  be  explicitly  guarded  by  a  check  for  exceptional  returns. 

Any  further  improvements  seem  to  require  pushing  the  effect  down  into  the  language 
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implementation  itself,  still  providing  a  purely  functional  interface  to  the  relevant  opera¬ 
tions,  but  implementing  them  more  efficiently  than  what  could  be  expressed  explicitly  in 
the  language.  In  particular,  several  proposals  have  been  made  for  direct  implementations 
of  state  in  languages  like  Haskell  [PW93,  LPJ95]. 

Unfortunately,  such  a  “black-box”  approach  negates  one  of  the  main  advantages  of 
the  denotational  approach:  the  ability  to  represent  effect  meanings  explicitly  as  ordinary, 
functional  constructs  that  can  be  reasoned  about  directly  within  the  language.  And  even 
more  significantly,  these  more  efficient  implementations  are  only  available  for  a  select  few 
effects;  programmer-defined,  application-specific  monads  cannot  take  advantage  of  any 
non-functional  implementation  techniques. 

1.1.2  “Effects  as  behavior” 

As  noted  in  the  previous  section,  there  are  some  compelling  advantages  to  the  denota¬ 
tional  approach  to  effects,  but  also  some  significant  practical  problems.  Whether  the 
former  outweigh  the  latter  is  still  a  controversial  issue,  especially  because  there  is  an 
alternative  way  of  treating  effects  in  programs.  This  approach  is  often  referred  to  by  the 
rather  loaded  term  of  “impure”  functional  programming;  we  will  generally  use  the  more 
neutral  names  behavioral  or  operational. 

The  basis  of  this  approach  is  that  a  program  expressed  in  terms  of  function  defini¬ 
tions  and  applications  can  still  be  given  a  very  natural  algorithmic  reading.  Specifically, 
the  fundamental  principle  of  applicative-order  reduction  (namely,  reducing  the  argument 
part  of  a  /5-redex  before  performing  the  substitution)  can  be  seen  as  specifying  a  partic¬ 
ular  sequencing  of  evaluations.  And  this  sequencing  can  serve  as  a  robust  skeleton  for 
organizing  general  computational  effects. 

Although  this  idea  can  be  traced  back  to  early  Lisp  [M+62],  perhaps  the  prototypical 
functional  language  based  on  such  an  approach  is  Scheme  [CR91].  The  three  key  semantic 
differences  distinguishing  Scheme  from  a  “purely  functional”  language  are  its  call-by- 
value  evaluation  strategy,  the  presence  of  explicitly  mutable  state,  and  a  feature  known 
as  first-class  continuations. 

These  three  characteristics  make  Scheme  a  very  versatile  language,  but  potentially 
significantly  complicate  reasoning  about  programs.  The  problem  is  not  that  call-bv- value, 
state,  or  continuations  are  inherently  particularly  hard  to  reason  about.  After  all,  they 
have  simple  denotational  counterparts,  and  any  Scheme  program  can  be  relatively  easily 
expanded  into  a  “purely  functional”  one  by  a  continuation-passing  transform. 

In  fact,  we  do  not  need  to  explicitly  translate  at  all;  direct-style  equational  theor¬ 
ies  such  as  the  computational  A-calculus  are  only  slightly  more  complicated  than  /577- 
conversion  [Mog89].  (The  situation  is  complicated  somewhat  by  dynamic  creation  of 
mutable  cells,  but  those  too  can  be  dealt  with  [FH92].)  It  would  thus  seem  that  ease 
of  reasoning  about  impure  functional  programs  should  be  “within  a  constant  factor”  of 
that  about  pure  programs. 

But  there  is  a  more  subtle  reason  why  general  Scheme  programs  can  be  much  harder 
to  analyze  formally  than  effect-free  ones:  because  the  set  of  computational  effects  is 
effectively  fixed  at  two  low-level  but  very  powerful  operations,  the  natural  programming 
style  consists  of  encoding  higher-level  effect  abstractions  imperatively  in  terms  of  the 
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available  effects,  rather  than  through  explicit  effect-passing. 

For  a  simple  example,  consider  parameterization.  Suppose  that  at  a  few  places  in  a 
program,  perhaps  spread  across  several  separately  compiled  modules,  we  need  access  to 
a  parameter  supplied  as  part  of  the  initial  expression  to  be  evaluated.  The  two  basic 
approaches  for  achieving  this  are  to  pass  the  parameter  around  everywhere  it  might 
eventually  be  needed,  or  to  store  its  value  in  a  global  cell  and  access  it  only  where 
actually  used. 

If  the  program  is  sufficiently  large,  and  the  accesses  to  the  parameter  sufficiently  in¬ 
frequent,  the  second  approach  becomes  the  natural  choice  (indeed,  probably  the  correct 
choice  from  a  software-engineering  perspective).  But  by  encoding  parameterization  in 
terms  of  state,  we  have  effectively  failed  to  represent  the  important  fact  that  the  para¬ 
meter  is  immutable. 

That  is,  suppose  the  program  were  otherwise  purely  functional.  Then  in  explicitly- 
parameterized  style,  we  could  easily  argue  that  the  phrase  / 3 p  +  f3p  could  always  be 
safely  replaced  by  2  x  /  3  p.  even  when  /  was  an  unknown  function.  But  once  we  admit 
general  state,  the  optimization  is  no  longer  automatically  valid:  we  need  to  be  able  to 
inspect  /,  making  sure  that  it  does  not  change  the  global  value  of  p.  before  we  can 
eliminate  the  common  subexpressions. 

In  other  words,  where  the  transformation  was  a  simple  equational  property  in  a  purely 
functional  setting,  it  is  at  best  only  provable  in  a  language  with  effects  when  /  and  all  the 
functions  it  calls  are  known.  The  reason  is  that  the  program  does  not  explicitly  embody 
the  specification  that  the  global  state  can  never  be  modified  after  its  initialization. 

Of  course,  in  a  purely  functional  language,  the  state-based  solution  would  not  be 
available  at  all.  Or,  more  accurately,  given  that  all  effects  in  a  pure  language  must  be 
written  out  in  full,  parameterization  would  naturally  be  expressed  as  such,  rather  than 
through  (functional)  state-passing.  That  is,  if  we  have  to  be  explicit  about  effects  anyway, 
we  may  as  well  be  precise. 

With  control  effects,  the  problem  is  of  course  compounded.  Again,  an  imperative 
realization  of  effects  such  as  exceptions,  nondeterminism,  or  concurrency  may  well  be 
practically  preferable  to  its  more  declarative  counterpart  in  explicit  effect-passing  style, 
but  the  price  we  pay  is  in  loss  of  simple  reasoning  principles. 

In  fact,  the  problem  is  not  only  in  analyzing  programs  using  the  effects:  it  is  often 
challenging  even  to  show  formally  that  the  implementation  of  the  effect  itself  is  correct. 
For  example,  in  Scheme  we  can  encode  (the  control  aspects  of)  an  ML-like  exception 
facility  in  a  few  lines  of  code  using  call/cc  and  a  “current  handler”  cell.  But  a  proof  that 
such  an  implementation  actually  agrees  with  the  explicit  exception-passing  used  in  the 
formal  definition  of  SML  [MTH90]  is  by  no  means  a  trivial  task. 

Similar  considerations  apply  to  analyzing  control-based  implementations  of  backtrack¬ 
ing  [Hay87,  HDM93]  or  concurrency  [Wan80]:  while  the  code  may  be  short,  elegant,  and 
intuitively  plausible,  formally  relating  it  to  a  more  abstract  denotational  specification, 
such  as  success  lists  [Wad85]  or  resumptions  [Sch86,  Mog90],  is  often  a  serious  undertak¬ 
ing. 

One  could  thus  say  that  it  is  in  this  sense  that  “purely  functional”  programs  offer 
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a  pragmatic  reasoning  advantage  over  “impure”  ones:  by  penalizing  all  effects  equally, 
they  do  not  discourage  the  use  of  precise,  custom-tailored  effect  representations.  Impure 
languages,  on  the  other  hand,  leave  us  an  unpleasant  choice,  trading  off  precision  against 
verbosity:  if  the  desired  effect  is  not  already  explicitly  available,  we  must  decide  whether 
to  encode  it  in  terms  of  some  more  general  standard  effect,  or  to  rewrite  the  program  in 
explicit  effect-passing  style. 

1.1.3  A  unified  view 

As  we  have  seen,  each  of  the  approaches  has  its  advantages  and  disadvantages.  The 
question  thus  naturally  arises,  whether  there  might  be  a  way  to  somehow  combine  the 
best  features  of  both.  In  particular,  would  it  be  possible  to  set  things  up  so  that  we  could 
think  (both  formally  and  informally)  in  terms  of  precise,  functional  denotations,  but  work 
(both  when  writing  and  executing  programs)  with  the  concise,  operational  behaviors? 

The  main  goal  of  this  thesis  is  to  answer  this  question  affirmatively.  We  will  see 
how  it  is  indeed  possible  to  take  a  purely  functional  denotational  specification  of  any 
monadic  effect  and  obtain  from  it  a  directly  executable  operational  implementation  using 
call/cc  and  state.  In  fact,  we  will  be  able  to  define  functions  for  converting  back  and  forth 
between  denotational  and  behavioral  views  of  the  same  effect  with  no  loss  of  information. 

The  fundamental  idea  is  to  distinguish  carefully  between  transparent  and  opaque  rep¬ 
resentations  of  a  computational  effect.  The  transparent  representation  is  the  explicit, 
denotational  one:  a  computation  that  may  raise  an  exception  is  represented  as  an  effect- 
free  computation  of  a  sum-typed  result;  a  computation  with  state-effects  is  represented 
as  a  pure  function  from  old  state  to  result  and  newT  state:  a  nondeterministic  computation 
is  represented  as  a  deterministic  computation  of  a  list  of  results:  and  so  forth. 

On  the  other  hand,  the  opaque  representation  is  effectively  an  abstract  data  type 
with  two  operations:  we  can  construct  a  trivial  computation  out  of  a  value,  and  we  can 
sequence  two  computations,  where  one  may  depend  on  the  outcome  of  the  other.  How 
these  operations  are  realized  depends  on  the  particular  notion  of  effects,  of  course.  But 
when  writing  the  bulk  of  a  typical  program,  the  opaque  representation  is  all  we  need. 
For  example,  a  program  written  in  monadic  style  would  mostly  use  abstract  unit  and 
bind  operations  for  structuring,  regardless  of  what  they  actually  expanded  to. 

Only  when  we  actually  wish  to  perform  an  effect,  such  as  raising  an  exception,  ac¬ 
cessing  the  store,  or  making  a  nondeterministic  choice,  do  we  need  additional  operations. 
For  such  explicit  effect-manipulations,  we  introduce  two  additional  operations,  converting 
between  transparent  and  opaque  representations  of  an  effect. 

That  is,  given  an  explicit  representation  of  the  effect,  such  as  a  value  representing  a 
raised  exception,  a  function  modifying  the  state,  or  a  list  of  possibilities,  we  can  obtain 
from  it  the  corresponding  opaque  representation,  which  can  then  be  further  combined 
with  other  opaque  computations  in  the  usual  way. 

Conversely,  and  equally  importantly,  from  an  opaque  representation,  we  can  recover 
its  transparent  counterpart.  For  example,  to  handle  an  exception,  we  explicitly  examine 
the  sum-based  representation  of  a  computation  and  perform  the  appropriate  action  in 
each  case.  Or  to  determine  whether  a  nondeterministic  subcomputation  has  at  least  one 
successful  outcome,  we  check  if  its  transparent,  list-based  representation  is  non-empty. 
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Although  this  distinction  may  not  at  first  appear  particularly  profound  or  useful,  we 
now  sketch  three  crucial  observations  that  together  summarize  the  main  contributions  of 
the  thesis  (with  each  one  roughly  corresponding  to  a  chapter): 

1.  Even  though  opaque  computations  are  a  priori  simply  another  abstract  datatype, 
the  two  operations  of  value-inclusion  and  sequencing  are  exactly  what  forms  the 
effect-backbone  of  an  “imperative  functional”  language  such  as  Scheme  or  ML.  In 
such  a  language,  any  subcomputation  may  have  an  effect.  A  value  such  as  a  constant 
or  a  lambda-abstraction  is  therefore  a  special  case,  which  must  be  implicitly  coerced 
into  a  general  computation.  This  corresponds  to  the  first  operation  on  our  ADT  of 
opaque  computations. 

Similarly,  effects  in  compound  computations  are  implicitly  sequenced  by  the  call-by¬ 
value  evaluation  order.  For  example,  in  an  application  Ei  E2,  first  E\  is  evaluated  to 
a  value,  then  E2,  and  finally  the  application  is  performed.  Again,  this  corresponds 
to  an  explicit  sequencing  of  opaque  computations,  where  subsequent  computations 
may  depend  on  the  values  produced  by  earlier  ones. 

With  this  view,  then,  the  conversions  between  transparent  and  opaque  represent¬ 
ations  of  computations  provide  an  effect- introspective  capability  in  the  language, 
exposing  the  underlying  notion  of  effects  when  and  only  when  it  matters.  That  is, 
the  two  operators  convert  between  computations  as  data  and  as  behavior  within  a 
single  setting,  integrating  the  views  of  effects  as  either  being  or  happening.  The  key 
requirement  is  that  the  two  conversion  operations  must  be  (two-sided)  inverses,  so 
that  no  information  is  lost  when  switching  between  the  two  view. 

That  is,  by  relaxing  the  relationship  between  transparent  and  opaque  represent¬ 
ations  from  their  being  identical  to  merely  isomorphic,  we  have  already  gained 
something  important:  a  model  for  programming  in  a  convenient,  concise  ML-like 
language,  with  an  intuitive  imperative  reading,  yet  at  the  same  permitting  equa- 
tional  reasoning  about  our  programs  as  if  they  were  written  purely  functionally, 
with  explicit  effect-passing.  But  we  can  actually  go  further: 

2.  Since  the  ultimate  goal  of  reasoning  about  programs  is  to  characterize  their  observ¬ 
able  behavior,  we  actually  have  some  freedom  in  choosing  the  opaque  representation 
of  effects,  as  long  as  we  can  guarantee  that  it  properly  tracks  the  transparent  repres¬ 
entation  in  all  complete  programs.  In  other  words,  we  only  need  to  ensure  that  the 
two  representations  are  obsej'vationally  isomorphic,  whether  or  not  they  actually 
are  denotationally  so. 

More  explicitly,  in  addition  to  the  canonical  opaque  representation,  which  simply 
encapsulates  the  specification  7nonad  of  the  transparent  representation,  there  may 
also  be  a  variant  opaque  representation,  based  on  a  different  implementation  monad. 
Then,  as  long  as  we  choose  the  implementation  monad  such  that  it  successfully 
mimics  its  specification  counterpart  in  all  program  contexts,  we  can  still  reason 
about  programs  as  if  opaque  effects  were  directly  represented  by  the  specification 
monad. 
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This  is  of  course  a  well-known  property  of  abstract  data  types  in  general.  In  our 
case,  however,  the  ADT  operations  of  value  inclusion  and  sequencing  are  implicitly 
invoked  at  every  single  subcomputation  (whether  it  actually  performs  any  effects 
or  not)  in  addition  to  the  explicit  conversions  between  transparent  and  opaque  rep¬ 
resentations.  Thus,  efficiency  of  the  implementation  becomes  a  significant  concern. 

We  will  consider  several  examples  of  such  effect-simulations,  and  give  a  general 
characterization  of  the  relationships  the  two  monads  must  satisfy  in  order  for  one 
to  act  as  the  opaque  representation  of  the  other.  But  perhaps  the  most  remarkable 
and  useful  such  instance  is  that,  under  suitable  assumptions,  any  7nonad  can  be 
simulated  by  a  continuation  monad.  In  particular,  this  means  that  no  matter  how 
apparently  complex  the  transparent  specification  may  be,  it  can  be  implemented 
uniformly  by  continuation-passing. 

This  further  adds  to  the  attractiveness  of  programming  with  monadic  effects:  we 
can  still  reason  about  our  programs  as  if  their  operational  behavior  were  realized  by 
explicit  effect-passing  according  to  a  (potentially  computationally  costly)  declarat¬ 
ive  specification.  Yet  the  actual  implementation  only  needs  to  incur  the  relatively 
low  (and  fixed)  cost  of  continuation-passing.  And  we  can  do  better  still: 

3.  Although  we  nominally  have  a  way  to  simulate  arbitrary  monadic  effects  with 
continuation  monads,  we  are  still  some  way  off  from  a  full  implementation  of  our 
hypothetical  ML-like  language  with  behavior-data  duality  for  user-definable  effects. 
We  have  shown  that  continuations  are  in  a  sense  a  universal  effect,  but  we  still  need 
to  actually  exploit  this  property  in  practice. 

A  key  third  step  is  therefore  to  note  that  the  variant  opaque  representation  of 
an  effect  is  also  the  canonical  opaque  representation  of  the  effect  induced  by  the 
implementation  monad.  That  is,  we  can  define  an  ML-like  language  with  a  notion 
of  native  effects  that  directly  corresponds  to  the  continuation  monads  we  use  for 
implementing  other  monadic  effects.  Any  language  in  the  style  of  (1)  above  can 
then  be  directly  embedded  into  this  one  language  of  control  effects. 

Moreover,  we  can  show  the  perhaps  equally  surprising  result  that  our  universal 
control-effect  language  can  itself  be  embedded  in  a  language  with  only  Scheme- 
style  first-class  continuations  and  mutable  global  variables.  This  could  be  said  to 
validate  the  informal  claim  in  the  Scheme  Rationale  for  call/cc  that  most  useful 
control  abstractions  can  be  implemented  explicitly,  without  changing  or  extending 
the  language  itself  [CR91]. 

With  this  correspondence,  we  have  effectively  bridged  the  gap  between  the  denota- 
tional  and  the  operational  view  of  effects:  we  can  reason  safely  in  terms  of  the 
former,  but  work  in  a  practical,  familiar  programming  language  in  terms  of  the 
latter.  The  general  construction  takes  a  non-trivial  amount  of  work  to  develop  and 
prove  correct,  but  we  only  need  to  perform  it  once  and  for  all,  not  once  for  every 
new  effect  we  want  to  implement. 

The  presentation  in  this  document  is  oriented  towards  call-by-value  languages,  which 
can  take  full  advantage  of  point  (1)  above.  Still,  there  is  in  principle  no  reason  why  (2)  and 
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(3)  could  not  also  be  exploited  in  a  purely  functional  language;  efficient  implementations 
of  effects  are  as  important  for  Haskell-like  languages  as  they  are  for  Scheme-like  ones. 
We  will  not  develop  the  details  of  such  an  application,  however. 

1.2  Monads  and  monadic  reflection 

In  this  section,  we  give  somewhat  simplified  introduction  to  monadic  effects.  In  particu¬ 
lar,  we  will  assume  that  the  monad  under  investigation  represents  the  only  computational 
effect  in  the  language.  The  formal  development  in  the  next  chapter  considers  a  more  gen¬ 
eral  notion  of  computation,  where  a  monad  serves  to  introduce  a  new  effect  on  top  of 
potentially  already  existing  ones.  Although  the  basic  idea  is  the  same,  the  details  become 
substantially  more  involved.  For  the  moment,  let  us  therefore  ignore  the  possibility  of 
effects  other  than  the  one  being  introduced. 

Monads  originate  in  category  theory;  like  many  such  concepts,  they  have  several 
equivalent  definitions.  For  our  purposes,  the  following  variant  (usually  known  as  the 
Kleisli  triple  formulation)  seems  most  convenient: 

Definition  1.1  (preliminary)  A  monad  T  in  a  functional  language  consists  of  the 
following: 

•  A  type  constructor  T - . 

•  For  any  type  a,  a  function  ija  :  a^-Ta  (the  unit  function  at  a). 

•  For  any  function  f  :  aq  — >  Ta %%  a  function  f*  :  Taq  — >■  Ta.2  (the  extension  of  f). 
These  coinponents  must  further  satisfy  the  three  monad  laws: 

f*°Va  =  f  <  =  id tq  (/*  °  <?)*  =  /*  o/ 

Remark  1.2  In  category  theory,  the  a  monad  is  conventionally  defined  in  terms  of  a 
functor  T  and  natural  transformations  7]  :  Id  — >■  T  and  //  :  T2  — >■  T  satisfying  certain 
equalities  [ML71,  VI.  1],  (In  the  context  of  functional  programming,  the  corresponding 
operations  are  usually  referred  to  as  map,  unit ,  and  join  [Wad92a].) 

It  is  easy  to  see,  however,  that  the  two  formulations  are  equivalent:  every  Kleisli  triple 
(T,  ?],-*)  determines  a  monad  (T,  rj,  fi)  by 

Tf  =  {v°fY  and  fia  =  \d*Ta  . 

Conversely,  every  monad  determines  a  Kleisli  triple  by 

r  =  up  otu), 

and  moreover  these  assignments  are  inverses.  In  the  following,  we  will  therefore  use  the 
terms  “Kleisli  triple”  and  “monad”  synonymously. 

A  simple  syntactic  variation  on  Kleisli  triples,  popularized  by  Wadler  [Wad92b],  uses 
a  binary  infix  operator  to  denote  application  of  an  extended  function,  writing  t  'bind'  / 
or  t*  f  for  our  f*t.  This  “continuation  last”  notation  is  usually  preferable  for  writing 
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actual  functional  programs  in  monadic  style,  but  the  formulation  in  the  definition  is  more 
convenient  for  our  purposes. 

It  should  also  be  mentioned  that  our  monads  are  properly  called  strong  monads  in 
category  theory  [Mog89],  essentially  because  the  /  being  extended  need  not  be  closed. 
(The  monad  laws  must  then  also  hold  for  open  terms;  the  formal  definition  in  the  next 
chapter  will  reflect  this.)  We  will  use  the  “functional  programming”  rather  than  the 
“categorical”  terminology  throughout  this  document.  ■ 

Monads  provide  a  uniform  framework  for  reasoning  about  computational  effects  (such 
as  state,  exceptions,  or  I/O)  in  applicative  programming  languages  [Mog89,  Mog91]. 
Informally,  ga  represents  a  “pure”  (i.e. ,  effect-free)  computation  yielding  a,  while  f*t 
represents  the  computation  consisting  of  t' s  effects  followed  by  an  application  of  /  to  the 
result  (if  any)  computed  by  t.  A  concrete  instance  may  help  clarify  this: 

Example  1.3  For  any  fixed  type  y,  the  monad  of  x~  carrying  exceptions  is  given  by 

Ta  =  a  +  x,  V  =  X  a.  ini  a,  f*  =  A  t.  case  t  of  ini  a  =>  /  a  |  inr  e  =>  inre 

Here,  a  computation  of  type  a  is  either  a  value  a  of  type  a  (the  left  summand),  denoting 
a  successful  computation  of  a,  or  a  value  e  of  type  y  (right  summand),  representing 
a  specific  failure.  The  unit  and  extension  operations  capture  the  expected  operational 
behavior  of  exceptions;  in  particular,  if  evaluation  of  a  function  argument  f  raises  an 
exception  e,  that  exception  is  simply  propagated  without  ever  applying  /.  It  is  easy  to 
check  that  these  definitions  do  in  fact  satisfy  the  equations  in  Definition  2.15.  ■ 

The  use  of  monads  for  structuring  purely  functional  programs  -  as  opposed  to  language 
semantics  -  is  by  now  quite  commonplace  [Wad92b,  PW93].  Of  course,  those  same 
structuring  techniques  can  usually  also  be  used  with  Scheme-like  languages  (only  rarely 
do  monadic-style  programs  rely  on  lazy  evaluation  in  a  fundamental  way),  but  the  benefits 
seem  less  clear:  often  a  “mostly  pure”  program  with  a  few  isolated  effects  (e.g.,  a  gensym 
or  occasional  output)  is  both  more  efficient  and  easier  to  understand  at  a  glance  than  an 
equivalent  “completely  pure”  program  expressed  in  monadic  style  throughout. 

There  is  a  more  interesting  way,  however,  of  explicitly  using  monads  as  a  structuring 
tool  for  programs  in  “impure”  functional  languages,  one  that  takes  full  advantage  of  an 
eager  evaluation  strategy  instead  of  trying  to  ignore  it.  The  study  of  this  alternative  is 
the  main  focus  of  this  thesis.  Specifically,  our  development  is  based  on  a  simple  functional 
language  based  on  “Moggi’s  principle”: 

Computations  of  type  a  correspond  to  values  of  type  Ta. 

As  also  noted  by  Moggi,  this  abstract  correspondence  principle  can  be  embodied  into 
a  concrete  language  construct  which  we  will  call  monadic  reflection  (by  analogy  to  the 
more  general  notion  of  computational  reflection  [Smi82,  WF88]).  Specifically,  we  take: 

Definition  1.4  (preliminary)  A  reflection  of  a  monad  T  in  a  language  is  given  by  two 
operators 

T  b  V  :  Ta 
T  h  iflV)  :  a 


and 


T  b  E  :  a 
F  b  [£]  :  Ta 


1 .2.  MONADS  AND  MONADIC  REFLECTION 


11 


satisfying  that  for  any  expression  E  :  a  (possibly  with  computational  effects)  and  any 
value  V  :  Ta, 


[T]  is  a  value ,  yu(  [£7] )  =  E,  and  [/i(C)]  =  V 

Although  the  presence  of  these  two  operators  arises  naturally  from  the  monadic  frame¬ 
work,  little  is  generally  said  about  their  computational  interpretation,  let  alone  their  use¬ 
fulness  in  actual  functional  programming.  As  it  turns  out,  however,  monadic  reflection 
provides  exactly  what  we  need  to  program  with  monadic  effects  without  having  to  rewrite 
the  code  in  monadic  style. 

In  operational  terms,  for  any  value  V  :  Ta,  n(V)  reflects  V  as  an  “effectful”  compu¬ 
tation  of  type  a:  we  can  construct  an  explicit  representation  of  the  effect,  then  perform 
or  execute  it  by  passing  it  to  //(-).  Conversely,  given  a  general  computation  E  :  a,  [T] 
reifies  it  as  the  corresponding  effect-free  value  of  type  Ta,  which  can  then  be  further 
inspected  and  analyzed  like  any  other  inert  piece  of  data. 

Although  it  is  possible  to  write  programs  using  the  reflection  and  reification  operators 
directly,  an  actual  programming  language  would  typically  define  a  collection  of  more 
convenient  operations  in  terms  of  //(-)  and  [-]: 

Example  1.5  Consider  again  the  exception  monad  from  Example  1.3.  We  can  express 
the  usual  exception-raising  construct  directly  as 

raise  E  =  let  e  =  E  in  //( inr  e) 

where  E  is  an  expression  -  typically  just  a  value  -  of  type  y.  That  is,  we  explicitly 
construct  a  right-tagged  value  in  the  explicit  representation  of  computations,  then  pass 
it  to  //(-)  to  perform  the  effect. 

Conversely,  [T]  reifies  a  possibly  exception-raising  a-expression  E  into  a  value  of 
type  a  +  y,  so  we  can  define  an  exception-handling  construct  like  this: 

try  E\  handle  e  =>  E2  —  case  \_E{\  of  ini  a  =»  a  |  inr  e  =>-  E2 

That  is,  if  £j  returns  normally,  E2  is  ignored,  but  if  £j  raises  an  exception,  the  handler 
E2  is  invoked  with  e  bound  to  the  exception  data;  a  general  pattern-matching  handle 
construct  as  found  in  SML  can  easily  be  expressed  in  terms  of  this  one.  ■ 


Example  1.6  For  any  type  a,  the  a -state  monad  is  defined  by: 

Ta  =  d->aX(j,  rj  =  A  a.  As.  (a,  s),  f*  =  A  t.  As.  let  (a,  s')  =  t  s  in  f  a  s' 

Here,  a  computation  t  is  represented  as  a  (pure)  function  accepting  a  current  state  s  and 
returning  a  value  a  and  a  new  state  s';  an  effect-free  computation  passes  the  state  along 
without  modifying  or  reading  it:  and  the  extension  of  /  first  evaluates  t  in  the  current 
state  s  and  then  fa  in  the  state  s'  resulting  from  evaluation  of  t. 
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Using  reflection,  we  can  define  operators  for  updating  and  reading  the  state: 

state  :=  E  =  let  v  =  E  in  //(As.  ((),  v)) 

!  state  =  n(\s.  (s,  s)) 

That  is,  state  :=  E  is  the  effect  represented  by  a  function  replacing  the  state  with  the 
value  of  E  (and  returning  ()  as  the  result  of  the  operation),  while  !  state  denotes  the  effect 
of  reading  the  current  state  without  modifying  it.  Neither  of  these  definitions  explicitly 
uses  the  reification  operator.  That  one  is  only  used  implicitly  at  the  top  level:  if  E  is  a 
program  with  state  effects,  then 

run  E  =  let  (a,  s')  =  [A]  s0  in  a 

is  the  result  of  evaluating  E  starting  with  an  initial  state  s0  and  discarding  the  final 
state.  A  simple  refinement  is  of  course  to  permit  the  state  to  persist  across  a  sequence 
of  top-level  evaluations,  as,  in  the  interactive  read-eval-print  loops  of  AIL  or  Scheme. 

Afore  generally,  if  we  take  a  to  be  a  whole  store  (a  finite  map  from  locations  to  values), 
we  can  define,  for  any  mutable  variable  x, 

x  :=  E  =  let'  v  <=  E  in  //(As.  ((),  s{Ix  u})) 

\x  =  //(A*.  (s(:x.  .s) ) 

where  tx  is  the  location  corresponding  to  the  cell  x. 

Note  that  the  state-accessing  operations  export  only  a  subset  of  the  functionality 
of  the  state  monad.  To  express  general  reflection/reification  in  the  store  case,  we  need 
access  to  a  “first-class  store”  mechanism.  This  can  actually  be  implemented  reasonably 
efficiently  using  version  trees,  without  requiring  the  whole  store  to  be  copied  [JD88, 
Alor93],  but  it  does  impose  some  overhead.  ■ 

The  latter  example  illustrates  that  it  may  not  always  be  feasible  or  desirable  to 
export  the  full  reflection/reification  pair  for  a  monad  in  a  real  programming  language. 
Nevertheless,  it  will  be  important  for  analysis  purposes  to  consider  the  fully  general 
formulation  of  an  effect  in  terms  of  //(-)  and  [-],  with  any  restrictions  on  accessible 
functionality  viewed  as  purely  pragmatic  considerations. 

This  is  not  to  trivialize  such  concerns,  only  to  emphasize  that  they  are  an  orthogonal 
issue.  Reflection  and  reification  expose  exactly  the  range  of  effects  expressible  in  the 
corresponding  state-passing  formulation  -  much  as  a  traditional  denotational  semantics 
of  a  language  with  a  store  does  not  formally  enforce  that  the  store  is  used  in  a  single- 
threaded  way. 

The  exception  and  state  monads  by  no  means  exhaust  the  interesting  possibilities. 
Some  other  examples  of  simple  monadic  effects  are  listed  in  Table  1.1;  we  will  encounter 
many  of  these  in  more  detail  later.  And  although  this  collection  may  still  seem  limited,  we 
have  not  even  considered  all  the  combinations  that  encode  multiple  effects.  For  example, 
Ta  =  o  — >■  (a  +  x)  Xcr  represents  computations  with  both  exceptions  and  state. 

(How  to  combine  specifications  of  individual  effects  into  composites  is  actually  a 
non-trivial  problem.  Although  we  will  not  develop  the  details  in  full  generality,  the 
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Common  name 

Functor,  Tot 

Unit,  rjn 

Extension,  f* 

Identity 

a 

X  a.  a 

x  t.  ft 

Partiality 

a |_ 

X a.  up  a 

At.  case  t  of  up  a  =>  fa  |  A  =>  _L 

Exception 

«  +  ,\ 

X a.  ini  a 

At.  case  t  of  ini  a  =>  fa  |  inr  e  =>  inr  e 

State 

o  — >■  a  x  o 

X a.  X s.  (a,  s ) 

At.  As.  let  (a,  s')  =ts  in  f  as' 

Environment 

c  — y  (y 

A  a.  Xe.  a 

At.  Xe.  f  (te)e 

Complexity 

a  x  N 

X a.  (a,  0) 

X  (a,  n).  let  (b,  n')  =  fa  in  ( b ,  n  +  n') 

List-nondeterm. 

a* 

A  a.  [a] 

A[al5 . . . ,  an].  f  ai  ++  •  •  •  ++  f an 

Set-nondeterm. 

fin & 

A a. {a} 

A  { o i , . . . ,  an }  ■  f  cq  U  •  •  •  U  f  an 

Continuation 

(cy  — y  o)  — y  o 

A  a.  Xk.  ka 

At.  Xk.  t(Xa.  f  a k) 

Table  1.1:  Some  simple  monads 


incremental  approach  used  in  the  next  chapter  to  layer  a  new  effect  on  top  of  an  existing 
one  illustrates  the  basic  principle:  we  must  refine  the  definition  of  a  monad  to  explicitly 
account  for  the  original  effects  in  the  new  specification.) 

1.3  Overview  of  the  thesis 

1.  This  Introduction  presents  some  background  material  about  computational  effects 
and  informally  introduces  the  notion  of  rnonadic  reflection  as  the  bridge  between 
the  denotational  and  operational  view  of  monadic  effects. 

2.  In  Programming  with  Monadic  Effects,  we  first  specify  a  simple  functional  base 
language  with  some  notion  of  ambient  effects,  such  as  partiality.  We  then  formally 
define  monads  in  this  setting  and  show  how  a  monad  T  induces  an  extension  of 
the  base  language  with  a  new  focus  effect.  We  specify  the  semantics  of  this  effect- 
enriched  language  by  a  simple  but  somewhat  impractical  (definitional)  monadic 
translation  back  the  original  language,  for  which  we  already  have  a  semantics.  Our 
task  in  the  remaining  chapters  will  then  be  to  devise  and  prove  correct  an  alternative 
implementation  of  the  extended  language. 

3.  Relating  Effects  contains  the  main  technical  contribution  of  the  thesis.  We  consider 
a  specification  monad  T  and  an  implementation  monad  U,  and  investigate  when 
U  can  be  said  to  simulate  T.  We  first  show  how,  given  some  data  connecting  T 
and  U,  we  can  define  a  variant  translation  from  the  T-extended  language  to  the 
base  language,  using  U-effects  to  perform  T-effects  (but  without  any  correctness 
guarantees  yet). 

After  some  technical  preliminaries,  setting  up  the  proof  context,  we  then  introduce 
the  concept  of  a  jnonad  relation  between  T  and  U,  and  show  that  given  such  a 
relation,  the  definitional  and  the  variant  translation  agree  on  complete  T-programs. 
In  many  cases  we  can  obtain  the  required  monad  relation  directly  from  existence 
of  a  monad  morphism  from  T  to  U,  but  the  general  continuation-simulation  of  T 
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with  a  continuation  monad  involves  an  additional  twist  to  capture  the  parametricity 
properties  of  the  “final  answer”  type. 

We  conclude  the  chapter  by  showing  that  the  correspondence  between  monads  and 
continuations  also  allows  us  to  define  the  monadic  reflection  operators  for  T  directly 
in  terms  of  those  for  the  continuation  monad  U.  Thus,  it  suffices  to  provide  an 
implementation  of  the  language  with  continuations  as  the  notion  of  focus  effect. 

4.  Completing  the  construction,  Implementing  Continuation- Effects  shows  how  the 
effects  corresponding  to  a  continuation  monad  can  be  embedded  into  a  Scheme-like 
language.  The  proof  can  be  broken  into  three  distinct  steps.  First,  we  show  that  the 
monadic  effects  for  continuations  can  be  expressed  in  terms  of  a  control  abstraction 
called  composable  continuations,  which  can  be  further  decomposed  into  three  even 
simpler  control  operators. 

Second,  we  show  that  the  distinction  between  ambient  and  focus  effects  introduced 
by  the  definitional  monadic  translation  does  not  actually  affect  evaluation,  thus 
leaving  us  to  implement  a  language  with  a  single  level  of  effects.  And  third,  we 
show  that  this  language  can  be  implemented  by  embedding  in  language  with  first- 
class  continuations  and  state.  We  conclude  by  showing  a  concrete  implementation 
of  the  construction  and  a  few  programming  examples. 

5.  Finally,  the  Conclusion  summarizes  the  results  and  outlines  some  promising  direc¬ 
tions  for  further  work. 


Chapter  2 

Programming  with  Monadic  Effects 


In  this  chapter,  we  introduce  a  simple  functional  programming  language  that  will  serve 
as  a  concrete  framework  for  the  results  and  proofs  throughout  the  thesis.  We  also  form¬ 
ally  define  the  notion  of  monad  in  this  setting,  and  show  how  a  monad  allows  us  to 
systematically  define  a  extended  language  with  a  new  notion  of  effects. 

2.1  The  base  language 

2.1.1  Terminology 

A  language  consists  of  a  syntax  L  and  a  semantics  C.  The  syntax  defines  the  sets  of  well- 
formed  types  and  of  well-typed  terms  of  a  given  type  by  means  of  a  language  signature , 
i.e. ,  a  set  of  type  constructors  and  (typed)  term  constructors  from  which  language  phrases 
are  built  up  inductively. 

The  semantics  assigns  some  notion  of  meaning  to  the  terms.  As  a  practical  minimum, 
we  expect  a  semantics  to  provide  a  notion  of  program  evaluation ,  i.e.,  a  partial  function 
Evaljr  from  a  suitable  subset  of  L-terms  (e.g.,  closed  terms  of  base  type)  to  some  set 
of  observable  results,  say  natural  numbers.  An  evaluation  semantics  induces  a  notion  of 
observational  equivalence  on  terms,  where  two  terms  are  considered  equivalent  if  they  can 
be  substituted  for  each  other  in  any  program  context  without  changing  the  observable 
outcome  of  the  program.  It  is  easy  to  see  that  this  relation  on  terms  is  in  fact  a  congruence 
wrt.  all  term  constructors  of  the  language. 

A  denotational  semantics  provides  more,  namely  a  rnodel.  That  is,  for  every  type,  a 
set  of  meanings  of  terms  of  that  type,  and  to  every  term  constructor,  a  meaning  of  the 
constructed  term  expressed  as  a  function  of  the  meanings  of  the  subterms.  In  particular, 
this  provides  a  notion  of  equality,  denotational  equivalence,  where  two  terms  are  equal  iff 
they  denote  the  same  element  of  the  model;  because  of  the  compositionality  requirement, 
denotational  equivalence  is  likewise  a  congruence.  Two  terms  may  be  observationally 
equivalent  without  being  denotationally  so,  but  it  is  usually  simpler  to  reason  about 
denotational  equivalence. 

We  obtain  an  evaluation  semantics  from  a  denotational  semantics  by  defining  a  func¬ 
tion  from  the  meanings  of  closed  terms  to  observable  results.  For  example,  the  denotation 
of  a  program  could  be  an  element  of  the  flat  domain  Ni  of  lifted  natural  numbers;  the 
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induced  evaluation  semantics  is  then  given  simply  by  the  evident  partial  function  map¬ 
ping  every  lifted  natural  number  to  itself,  and  undefined  on  the  _L-element  of  the  domain. 
Two  different  semantics  for  a  syntax  (say,  direct  and  continuation)  may  determine  the 
same  evaluation  semantics  (and  hence  the  same  notion  of  observational  equivalence),  but 
induce  different  notions  of  denotational  equivalence. 

We  say  that  a  language  ( L ,  C)  is  a  member  of  a  language  class  (e.g.,  the  class  of 
lambda-calculi)  if  its  signature  contains  some  specified  set  of  type  constructors  (product, 
function  space,  etc.)  and  term  constructors  (abstraction,  application,  etc.),  and  the 
meanings  of  these  types  and  terms  in  C  satisfy  some  equational  constraints  (congruences, 
/5-conversion,  etc.).  Often  we  can  prove  a  result  for  an  entire  class  of  languages  by  showing 
that  it  holds  genericallv  in  any  model  of  the  equations. 


2.1.2  The  base  syntax 

We  now  present  a  concrete  language,  in  which  we  will  be  doing  most  of  the  formal 
development.  Its  syntax  and  semantics  are  very  similar  to  PCF  [Plo77]  (even  more  so 
to  PCF  with  lifted  types  [Mit96],  except  that  the  effect  structure  is  made  more  explicit. 
We  call  it  Effect-PCF.  We  present  the  syntax  and  informal  operational  interpretation  in 
this  section,  with  a  precise  denotational  semantics  in  the  next. 

Effect-PCF  is  somewhat  more  verbose  than  a  typical  practical  programming  language, 
because  all  computation  sequencing  is  made  explicit  in  the  syntax.  For  example,  in  an 
application,  both  the  function  and  the  argument  must  be  explicitly  evaluated  if  they  are 
not  already  values. 

Although  we  could  have  worked  in  an  ML-like  CBV  language  directly,  the  general 
treatment  of  monadic  effects  becomes  awkward  when  the  sequencing  is  left  implicit.  The 
present  formulation  allows  us  to  cleanly  separate  out  the  handling  of  effects  from  the 
“purely  functional”  structure  (exponentials,  products,  etc.). 

Moreover,  there  is  a  simple,  effect-independent  elaboration  of  a  standard,  ML-like 
syntax  into  Effect-PCF,  so  we  can  view  the  implicit  sequencing  of  computations  in  call- 
by- value  languages  as  merely  convenient  shorthand  for  the  corresponding  Effect-PCF 
terms.  We  will  return  to  this  elaboration  in  Section  2.1.6. 

The  base  signature  is  displayed  in  Figure  2.1. 


Type  structure 

The  most  notable  characteristic  of  the  syntax  is  the  division  of  the  types  into  two  classes: 
value  types  (a),  and  a  subset  called  (generalized)  computation  types  (/5).  The  operational 
significance  of  this  division  is  to  make  the  possibility  of  effects  explicit  in  the  types, 
separating  trivial  or  manifestly  effect-free  from  serious  computations. 

We  make  value  types  properly  include  computation  types  by  taking  one  possibility 
for  a  value  to  be  an  unevaluated  computation,  represented  by  a  value  of  type  °«.  For 
example,  a  closed  expression  of  type  i  will  always  be  equivalent  to  a  numeral:  a  general 
expression  expected  to  yield  a  natural  number,  but  which  may  diverge  (or  have  some 
other  effect)  has  type  °i. 
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Types: 

a  ::=  a  |  i  \  1  |  a.\  X  q!2  |  ai  +  a:2  |  0 
f3  ::=  °a  |  a  — >■  j3  |  1  |  /?x  ^  fa 

Terms: 

M  ::=  x  |  z  |  sM  |  ifz (M,  Mls a:.  ,M2)  |  ()  |  (MUM2)  |  fst  M  |  snd  M 
|  ini  M  |  inrAf  |  case  ( A/,  .'i .  A/; .  ./2.  A /•<)  |  A./".  A/  |  A/;  M2 
|  °M  |  let”  :r  -<=  in  M2  |  fix  ;  A  / 

Typing:  F  is  a  type  assignment  Xi.  ol5 . . . ,  ;r„:  (with  all  Xf  distinct). 

(x:  a)  G  T  F  h  M  :  l 

rhi:a  r  b  z  :  l  T  b  s  M  :  l 

T  b  M  :  l  T  b  Mz  :  a  T,  x:  l  b  Ms  :  a 

F  b  ifz  (A/.  A/, .  x.  A  I, )  :  a  F  b  ()  :  1 

r  b  Mi  \  Q-i  F  b  M2  :  ct2  F  b  M  :  cti  X  a2  F  b  M  :  cti  A:  a2 

F  b  (Mi,  M2)  :  a  .  X  n2  F  b  fst  A/  :  a .  F  b  snd  A/  :  n2 

r  b  M  :  rv  i  r  b  M  :  o2 

T  b  ini  M  :  cti  +  o;2  T  b  inr  M  :  a\  +  a:2 
F  b  M  :  cvi  +  a2  F.  ;ri:  ctj  b  M\  :  a  F.  x2:  a2  b  M2  :  a 
F  b  casef  A/../  i.A/;..r2.A/2)  :  a 
r,i:ab  M  :  (3  F  b  Mi  :  a  — >■  {3  F  b  M2  :  a 

r  b  A:b\AF  :  a ->  0  r  b  M1 M2  :  /? 

r  b  A/.  :  ft  F  b  M2  :  ft  r  b  M  :  ft  *  ft  1  b  M  :  &  *  ft 

T  b  (Mi,  M2)  :  fa  Z  fa  V  ■  fst  A/  :  ft  T  b  snd  A/  :  ft 

r  b  A/  :  o  r  b  Mx  :  ax  F.  ;r:  Ql  b  M2  :  °«2  T  b  M  :  Q  -)•  Q 
r  b  °M  :  °«  r  b  let°  ./•<  A/i  in  M2  :  «2  F  fix  ;  A/  :  i 


Figure  2.1:  Base  signature,  L0 
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A  computation  of  type  a— >■/?  is  often  more  conveniently  thought  of  as  /^-computation 
parameterized  by  an  o-valuc.  rather  than  as  a  function  from  values  to  computations. 
In  particular,  when  f3  is  itself  an  arrow  type,  no  actual  evaluation  occurs  until  all  the 
parameters  are  present. 

Similarly,  a  computation  of  type  3\  Z.  3->  can  be  viewed  as  a  single  computation  impli¬ 
citly  parameterized  by  the  choice  of  which  component  to  evaluate,  not  as  two  unrelated 
computations.  (In  the  case  where  3i  and  /32  are  the  same  type  3,  this  is  reflected  in  the 
isomorphism  .)A  (I  |  I)  >3.) 

There  are  actually  two  product-type  constructors,  one  for  value  types  and  one  for 
computation-types  only.  Although  their  typing  and  equational  properties  are  identical 
(and  in  the  standard  semantics,  they  are  even  interpreted  by  the  same  cpo  constructor), 
the  two  variants  are  logically  distinct.  Still,  we  generally  omit  the  superscripts  when  it 
is  clear  which  one  is  meant  -  i.e.,  when  one  of  the  factors  is  a  value  type,  or  the  context 
requires  a  computation-type. 

(Analogous  consideration  apply  to  the  unit  type,  of  course,  but  there  we  can  simply 
assume  that  the  two  types  are  identical  without  unduly  constraining  the  semantics.) 

The  set  of  value- types  also  includes  a  countable  set  of  type  variables.  (There  are  no 
type  variables  for  the  computation-types.)  When  A  =  {ai, . . . ,  a„  }  is  a  finite  set  of  type 
variables,  we  write 

bA  a  type  and  bA  3  ctype 

if  all  type  variables  occurring  free  in  a  and  3  are  in  A;  in  this  case  we  say  that  a  or  3 
is  a  type  over  A.  Clearly  when  A'  D  A  then  also  bA/  a  type  and  bA/  3  ctype.  We  say 
that  a  and  3  are  (type-) closed  when  A  is  empty.  A  type  over  A  determines  a  type  family 
consisting  of  all  types  obtained  by  substituting  closed  types  for  type  variables  in  A. 

Note  that  there  are  no  constructs  within  the  language  for  explicitly  binding  type 
variables.  (There  will  be,  however,  in  an  extension  of  Lq  with  recursively-defined  types 
in  Section  3.2.1.) 

The  canonical  model  of  the  language  is  given  by  the  category  of  “bottomless”  epos 
(predomains)  and  continuous  functions,  with  computation-types  interpreted  by  pointed 
epos  and  the  “-operator  on  types  corresponding  to  lifting.  See  Section  2.1.3  for  details. 

Terms 

The  term  structure  and  associated  typing  rules  are  again  mostly  conventional.  Similarly 
to  the  parameterization  of  types  by  type  variables,  we  write 

T  bA  M  :  a 

if  all  type  variables  occurring  free  in  T,  M,  and  a  are  listed  in  A.  M  is  then  said  to  be  a 
term  over  A;  again  it  is  called  type-closed  when  A  is  empty,  and  the  set  of  type-closed 
instances  of  a  term  over  A  forms  a  term  family. 

Complementing  the  “-operator  on  types,  there  is  a  term  operator  “M,  which  constructs 
an  effect-free  computation  returning  M,  and  let“  x  -<=  M\  in  M2,  which  constructs  a 
computation  consisting  of  evaluating  Mi  and  M2  in  sequence,  with  x  in  the  second 
evaluation  bound  to  the  result  of  the  first  one.  A  computation  is  treated  as  a  first-class 


2. 1 .  THE  BASE  LANG  UAGE 


19 


object,  and  is  not  actually  performed  until  its  value  is  explicitly  requested,  either  directly 
by  a  top-level  program  evaluation,  or  through  evaluation  of  an  enclosing  let. 

We  generally  omit  the  type  tags  in  terms  when  they  are  clear  from  the  context.  Also, 
we  will  occasionally  use  pattern-matching  syntax  in  let-  and  lambda-bindings,  with  the 
usual  expansions,  e.g., 

(let°  {xi,x2)  <=  M  in  M')  =  (let°  x  <=  M  in  M'{ fstz/aq,  snd  x/x2})  (x^fv(m')) 

(Note  that  the  projections  are  considered  to  be  trivial  by  the  typing  rules,  so  the  result 
of  the  substitution  is  still  well-typed.) 

The  constructs  associated  with  type  i  allow  us  to  program  with  natural  numbers  using 
a  zero-constant,  a  successor  function,  and  a  combined  zero-test /predecessor  operation. 
Given  general  recursion,  we  can  construct  the  standard  arithmetic  operations  out  of  those 
primitives.  For  example,  we  can  define  addition  as: 

plus  :ixh  °l  =  A  (ni,  n2).  (A/.  An.  ifz  (n,  °n2,  n'.  let”  r  <=  f  n!  in  °(s  r)))  nx 

Note,  however,  that  because  of  the  use  of  fix,  the  result  of  an  addition  is  an  l- computation, 
even  though  the  addition  function  happens  to  be  total.  (We  could  of  course  extend  the 
language  with  additional  primitives  for  arithmetic  or  a  primitive-recursion  construct, 
which  could  then  be  given  pure  value-types.) 

Having  fixed  points  at  all  computation-types  3  also  allows  us  to  express  mutual 
recursion  easily,  as  in: 

even  :  t.  — >  °2 

=  fst  (fix(t^-2)x(t_V2)  (A(e,  o).  (An.  ifz  (n,  °( ini  ()),  n  .  on),  An.  ifz  (n,  °( inr  ()),  n.  en)))) 

where  2  =  1  +  1  is  the  type  of  Boolean  values. 

On  the  other  hand,  we  cannot  write  down  a  term  corresponding  to  a  fixed  point  of 
the  pure  successor  function;  indeed,  the  type  /.—>■/.  is  not  even  expressible  in  the  language. 
(We  can  write  fix-t  (A/"',  let”  n  <=  I  in  °(sn))  :  Not  surprisingly,  this  denotes  a  diverging 

computation  in  the  intended  interpretation  of  fix.) 

Finally,  we  occasionally  use  the  standard  abbreviations: 

rhMpa^  3l  r  b  M2  :  3i  ->•  32 
1%  id  ;  :  3  >3  r  •  ,\T  O  .1/,  :  n  >  i. 


r  b  :  3 


rbn: 


-(neN) 

l 


with  id/3  —  Ax/3.x ,  M2  o  Mi 


d=b  A xa.M2  {Mix),  _Lp  &  fiX/3  id/?,  and  n  =  sn  z. 


2.1.3  A  denotational  semantics 

A  program  in  our  base  language  is  a  closed  term  of  type  °a;  if  in  the  semantics  that  term 
is  equivalent  to  °n  for  some  n,  the  program  denotes  a  successful  computation  with  result 
??.;  otherwise,  a  diverging  computation.  A  denotational  semantics  gives  the  meaning  of  a 
complete  program  by  induction  on  its  syntactic  structure. 


20 


CHAPTER  2.  PROGRAMMING  WITH  MONADIC  EFFECTS 


Preliminaries  We  give  a  simple  model  of  the  base  language  in  the  setting  of  bottomless 
epos  (also  called  pre-domains ),  i.e. ,  complete  partial  orders  not  necessarily  having  a  least 
element.  For  completeness,  we  review  the  associated  terminology  and  constructions. 

Definition  2.1  A  epo  A  is  a  set  equipped  with  an  uo-complete  partial  order  C,  i.e.,  such 
that  every  countable  chain  «i  Q  a2  C  •  •  •  of  elements  in  .4  has  a  least  upper  bound,  written 
\_\i  <>i  ■  A  monotone  (=  order-preserving )  function  from  .4  to  A!  is  called  continuous  if  for 
every  chain  in  .1.  /(|_|,-«i)  LI;  /(";)• 

A  epo  B  is  called  pointed  if  it  has  a  least  element  Tb,  be.,  if  Tb  Q.  b  for  every  b  in 
B.  A  function  between  pointed  epos  B  and  B'  is  called  strict  «/ /(_!_#)  =  J -b1  ■  We  use 
the  name  domain  synonymously  with  pointed  epo. 

There  are  a  number  of  standard  epos  and  epo  constructions: 

•  base  types.  Any  set,  such  as  the  natural  numbers  N,  can  be  organized  as  a  epo 
by  equipping  it  with  the  discrete  ordering ,  n  CN  n1  iff  n  =  n' . 

•  unit  type.  The  one-element  set  1  =  {*}  is  trivially  a  epo.  It  is  even  degenerately 
pointed,  with  _l_i  =  *. 

•  products.  .4]  x  A2  is  the  cartesian  product  of  epos,  ordered  componentwise  (i.e., 
(01,02)  EAixA2  (a\ ,  of )  iff  01  TAl  o/|  and  a2  EAi  a'2).  If  B\  and  B2  are  pointed  then 
so  is  B1  x  B2,  with  ±Bixb2  =  (TSl,T Bo). 

•  sums.  Ax  +  A 2  is  the  disjoint  union  of  epos  (note:  not  the  “separated  sum”  from 
standard  domain-theoretic  notation), 

Ai  +  A2  =  {(1,  oi)  |  ai  G  Ai}  U  {(2, 02)  |  02  G  A2} 

ordered  inject-wise,  i.e.,  ( i,a )  Cy4l+y4,  ( i',a ')  iff  i  =  i'  and  a  CA.  a'.  Such  a  epo  is 
in  general  not  pointed,  even  if  the  summands  are. 

•  function  space.  A\  -tt  A2  is  the  epo  of  continuous  functions  from  A\  to  A2,  with 
/  Ty4l_g.4.,  f  if  Vo  G  Ai.f(a)  Cy4,  f'{a).  To  minimize  confusion  with  abstraction 
and  application  in  the  language,  we  write  A x.<p(x)  and  f(a)  for  abstraction  and 
application  in  the  epo  model.  A  — >■  B  is  pointed  when  B  is,  with  T a_>b  =  A x.Eb- 

•  lifting.  For  any  epo  A,  we  define  the  lifted  epo, 

A±  =  {{a}  |  a  G  A}  U  {0} 

ordered  such  that  {a}  EA±  {a7}  if  a  C  4  a7,  and  0  C  {a}  for  any  a.  We  write  up  (a) 
for  {a}  and  _L  for  0.  Naturally,  Aj_  is  pointed. 

The  strict  extension  of  a  function  /  :  A  — >■  A7±  is  the  function  :  A±  — )■  A7±  given  by 
/^(up(a))  =  /(a)  and  /t(_L)  =  T.  More  generally,  for  any  pointed  B  and  /  :  A^B, 
/+  :  A±  — >■  B  maps  up(a)  to  /(a)  and  J_A±  to  ig. 

•  reflexive  types.  Finally,  the  CPO  model  allows  us  to  construct  solutions  (up  to 
isomorphism)  to  recursive  type  equations.  While  we  will  not  need  this  immediately, 
it  will  become  important  in  Section  3.2.1. 
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Given  a  finite  set  /,  we  write  Yhei  Af  for  the  /-indexed  product  of  epos,  i.e. ,  the  set 
of  functions  p  :  /  — >■  U?;e/  A,  such  that  for  each  i  £  /,  p(i)  £  A*.  Such  a  function  is  usually 
called  an  environment.  Environments  can  be  naturally  ordered  pointwise,  with  p  jZ  p'  iff 
Vi  £  I.  p(i)  I  ,1, 

Finally,  we  write  •  for  the  empty  environment;  p[i'  i— »a]  £  1 1;  /  ,■  .1;  (where  i'  may 
or  may  not  already  be  a  member  of  I)  for  the  function  mapping  i!  to  a  £  A,;/  and  every 
other  i  £  I  to  p(i);  and  p\i  for  the  function  p  restricted  to  I  \  {/}. 

Base  effects  To  give  a  semantics  to  our  language  in  the  predomain  model,  we  first 
need  to  choose  a  notion  of  base  or  ambient  effects,  to  be  denoted  by  the  computation- 
type  constructor.  The  canonical  example  of  such  an  effect  is  partiality,  but  the  structure 
of  the  later  proofs  is  largely  independent  of  the  exact  choice;  we  only  need  to  show  that 
it  satisfies  a  few  simple  relational  properties. 

We  treat  the  case  of  partiality  formally,  and  sketch  how  the  setup  generalizes  to  other 
ambient  effects  where  appropriate.  We  do  not  develop  the  semantics  of  ambient  effects 
in  detail,  however;  where  possible,  it  is  more  convenient  to  treat  ambient  effects  more 
uniformly,  using  the  monadic  translations  to  be  introduced  a  little  later. 

A  valid  reason  for  considering  more  complicated  base  effects,  however,  is  to  model  lan¬ 
guage  features  that  cannot  be  eliminated  by  a  source-to-source  transform.  For  example, 
“true”  non-determinism  (as  opposed  to  a  finitary  variant,  which  can  be  defined  by  a 
backtracking  transformation),  can  be  modelled  by  a  powerdomain  or  similar  construct. 
Similarly,  any  notion  of  I/O  operations  or  other  extra-linguistic  effects  must  somehow  be 
accounted  for  in  the  semantics  rather  than  at  source  level.  We  will  not  treat  any  of  those 
formally,  however. 

Definition  2.2  An  ambient-effect  monad  for  the  epo  semantics  is  given  by  the  following 
data: 

•  A  epo  constructor  T,  such  that  for  any  epo  A,  T A  is  a  pointed  cpo. 

•  A  family  of  continuous  functions  (a  :  A  — >•  T A. 

•  An  assignment  to  any  continuous  function  f  :  A— )>TA' ,  a  strict  continuous  function 
/°  :  T A  —t  TA1 .  This  assignment  must  itself  be  continuous,  i.e.,  satisfy  the  equality 

(U,/,)°  =  □,/?. 

Further,  the  components  must  satisfy  the  three  monad  laws: 

r°U  =  !  Q  =  i<U.4  f«j"=(f«9r 

Definition  2.3  The  partiality  semantics  is  given  by  taking  TA  =  Aj_  (pointed,  as  re¬ 
quired),  ((a)  =  up  (a),  and  /°  =  p  (strict  by  definition).  It  is  easy  to  check  that  the 
monad  laws  hold  for  this  triple. 

(Incidentally,  the  requirement  that  /°  be  strict  ensures  that  £4  :  A^—?T A  is  a  monad 
morphism  from  the  partiality  monad  to  T.  We  will  phrase  this  in  more  general  terms  in 
Definitions  2.11,  2.15,  and  3.1,  and  in  Example  3.2.) 
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Semantics  of  types  To  every  well-formed  Ha  «  type,  we  assign  a  cpo,  and  to  every 
Ha  P  ctype,  a  pointed  cpo: 


£[a]  =  da 
£[/]  =  N 
^[1]  =  1 

£[«i  X  a2]  =  £[«i]  x  £[a2] 
£[<Tl  +  »2]  =  £[«i]  +  £[02] 
£[a  ^  Pi  =  £[«]  — >■  £[,5] 

cipi  * P2]  =  cm  x  cm 

£[«]  =  r  (£[«]) 


Semantics  of  terms  To  every  well-typed  T  Ha  M  :  0,  we  assign  an  element  £[M]0  e 


C{xj{p) 

cM(p) 

£[s  M\{p) 
£[ifz(M,  Mz,x.  Ms)\(p) 

ciOM 

£[<M1jM2)](/9) 
£[fst  M}(p) 
£[snd  Mj{p) 
£[ ini  M}{p) 
£[ inr  M}(p) 

C  ease  (M,  x1.M1,x2.M2)\{p) 

C\Xx.  Mj(p) 
C[Mi  M2](p) 
£[°M](p) 
£[let°  x  -<=  Mi  in  M2](p) 
£[fix/j  M](p) 


p{x) 

0 

£[M](p)  +  1 

r  £[Ms](p)  when  £[M](p)  =  0 

1  £[Ms](p[a;  1— )►  n\)  when  £[M](p)  =  n  +  1 
* 

ai  when  £[M](p)  =  (ol5a2) 
a2  when  £[M](p)  =  (ax,a2) 

(l,£[M](p)) 

(2,  £[M](p)) 

r  £[Mi](p[^-i  h^ai])  when  £[M](p)  =  (l,ai) 
1  £[M2](p[x2  e^a2])  when  £[M](p)  =  (2,a2) 

Aa.£[M](p[;£  a]) 

£[M1](p)(£[M2](p)) 

e(^[M](p)) 

(Aa.£[M2](p[^^a])r(£[M1](p)) 

U,,(£[M](p))''(T£M) 


(where  for  any  i  >  0,  /'  is  the  z-th  iterate  of  /,  i.e. ,  /°(a)  =  a  and  /,+1(a)  =  /(/*(«))). 


Figure  2.2:  Denotational  semantics  C°(T of  the  base  language 
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Other  examples  can  be  easily  adapted  from  the  source-level  monads  to  be  presented 
in  Section  2.2.3;  for  example,  we  obtain  a  notion  of  ambient  state  by  taking  TA  = 
N  — >■  {A  x  N)_l,  cf.  Example  2.18.  However,  such  L0-definable  ambient  effects  are  more 
conveniently  dealt  with  at  the  syntactic  level,  through  an  explicit  monadic  translation. 

Although  the  only  explicitly  accessible  effect  in  our  base  language  is  divergence  (via 
fix),  it  is  still  useful  to  consider  more  general  effect-structures  in  the  semantics.  For 
example,  a  continuation  semantics  may  well  be  of  interest  even  for  a  language  that  does 
not  contain  explicit  control  operators. 

We  can  now  give  a  denotational  semantics  of  the  base  language  (parameterized  by 
the  choice  of  effect  structure)  in  Figure  2.2.  Let  A  be  a  finite  set  of  type  variables,  and  6 
be  a  mapping  of  type  variables  in  A  to  epos.  The  semantics  then  assigns  to  every  A-type 
Fa  Of,  a  epo  £[«[0  (pointed  if  a  is  computational),  and  to  every  A-term  F  Fa  M  :  a, 
a  continuous  function  £[M]°  from  £[r]0  =  1 1 :o  •.  |£/>AW  to  A[o]0.  (We  usually  omit 
6  when  it  is  clear  from  context.  In  particular,  since  there  are  no  language  constructs 
for  binding  type  variables,  6  stays  constant  throughout  the  semantic  equations,  and  is 
omitted  throughout  the  figure  to  reduce  clutter.) 

Although  the  denotational  semantics  thus  assigns  meanings  to  types  and  terms  over 
arbitrary  As  (interpreting  type  variables  by  arbitrary  epos),  for  most  purposes  we  will  not 
use  this  generality;  syntactic  substitutions  of  closed  types  for  type  variables  suffice.  The 
only  uses  of  the  ^-parameterized  semantics  are  in  showing  that  a  syntactic  monad  may 
be  used  to  express  a  semantic  one  in  Proposition  2.20,  and  when  introducing  recursively- 
defined  types  in  Section  3.2.1. 


2.1.4  Generalized  let 


Definition  2.4  For  any  computation-type  0  of  L() ,  we  define  a  derived  term  constructor 
let?,  the  generalized  let  with  typing  rule 

r  F  Mi  :  °a  T,  x:  a  F  M2  :  0 

V  ■  let,./-  <  .1/,  in  M,  :  0 


by  induction  on  the  structure  of  0: 


let°Q  x  -<=  M\  in  M2 
let)  x  -<=  Mi  in  M2 

let/3lX/3o  x  <  M1  in  M2 

let.,,  . ,  x  <  Mi  in  M2 


let°  x  -<=  Mi  in  M2 

0 

(let')ir  x  <t=  Mi  in  fst  M>.  let^o  x  Mi  in  snd  M2) 
AaQ.letg  x  Mi  in  M2 a 


In  the  predomain  semantics  (for  any  T),  two  particular  consequences  of  this  definition 
are: 


£[let^  x  <=  Mi  in  M2](p)  =  | 


C{M2\(p[x  a]) 

-L-CI/3] 


when  C\Mi\(p)  =  £(a) 
when  £[Mi](p)  =  A 


In  the  case  of  the  partiality  semantics,  these  are  in  fact  the  only  two  possibilities  for 
£[Mi](p).  We  thus  obtain  a  natural  generalization  of  the  existing  “strict  extension” 
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let,  in  that  M2  can  now  be  of  a  type  interpreted  by  any  pointed  cpo,  not  necessarily  a 
directly  lifted  one.  Note,  however,  that  we  still  need  to  restrict  Mi  to  be  of  type  °a,  not 
a  general  computation  type:  while  strictness  makes  sense  for  functions  B\  — >■  B>  between 
arbitrary  pointed  epos,  the  strict  extension  operation  can  only  extend  a  function  A—rB 
to  A±  — >■  B ,  not  “strictifv”  an  arbitrary  function  Bx  — >■  B2. 

It  is  important  to  note  the  difference  between,  say,  a  computation  returning  a  pair  of 
integers: 

let°(ixO  x  ^  M  *n  °(xw) 


(where  M  is  evaluated  exactly  once,  yielding  a  pair  of  numbers),  and  the  construction  of 
a  pair  of  computations: 

let°tx=t  x  <=  M  in  (°x,  °5) 


(where  M  is  evaluated  when  either  component  of  the  result  is  requested).  Similarly,  we 
distinguish  between  the  diverging  computation  of  a  function: 


y  <=  -L*t  in  °(Xx.  °3)  :  m(i  ->■  °t) 

and  a  successful  computation  yielding  a  function  which  diverges  for  all  inputs: 

°(letW  y  <=  WL  in  (Aax°3))  :  °{i  ->■  °i) 


2.1.5  Equational  properties 

When  the  semantics  C  is  fixed  and  clear  from  context,  it  is  often  preferable  to  reason 
about  programs  at  the  level  of  terms,  rather  than  explicitly  about  their  denotations  in 
the  semantics.  More  generally,  we  can  often  isolate  a  set  of  reasoning  principles  that  hold 
for  a  large  variety  of  interpretations,  then  check  that  our  specific  semantics  C  verifies 
those  principles. 

As  mentioned  before,  for  our  purposes,  it  will  suffice  to  consider  equational  properties 
of  type-closed  terms  (i.e. ,  with  no  free  type  variables),  although  the  following  should 
extend  naturally  to  type  and  term  families  over  a  nonempty  set  of  type  variables. 

Definition  2.5  A  signature  L  consists  of  a  set  of  type  and  term  constructor's.  An  in¬ 
terpretation  C  of  L  assigns  to  every  type  b®  a  type  of  L,  a  set  Val(o:);  and  to  every 
L-term  T  b@  M  :  a  and  finite  function  p  with  V(:r*:  cti)  €  T.  p{xf)  G  Val(cq),  an  element 
lnt{M)P  e  Val(a). 

An  equational  theory  £  for  L  is  a  set  of  typed  equalities  between  (type-closed)  L- 
terms,  V  b  M  =  AT  :  a.  A  model  of  an  equational  theory  is  an  interpretation  that 
satisfies  all  the  equations  of  the  theory,  i.e.,  whenever  T  b  M  =  AT  :  a  is  provable  and  p 
is  a  T- environment,  then  Int (M)p  =  Int (M')p  as  elements  ofVal(a). 

It  is  clear  that  the  predomain  semantics  (for  any  notion  of  ambient  effects  T)  determ¬ 
ines  an  interpretation  of  L0,  by  taking  Val(o:)  as  the  set  underlying  £[«]  and  lnt(M)p 
as  £[M](p),  forgetting  continuity  of  £[M]  (as  a  function  from  environments  to  values). 
We  present  an  equational  theory  £o  for  L0  and  simultaneously  argue  that  the  predomain 
interpretation  is  a  model  of  that  theory.  For  particular  classes  of  Ts,  additional  equations 
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may  be  axiomatizable,  for  example  that  ambient  effects  are  commutative  or  idempotent; 
we  do  not  consider  such  extensions,  however. 

In  most  cases,  the  axioms  listed  below  can  be  immediately  verified  by  referring  to 
the  semantics;  we  often  omit  the  details  where  they  can  be  easily  filled  in.  Also,  since 
equality  judgments  are  always  about  type-closed  terms,  we  omit  the  implicit  hg  in  all 
typing  assumptions  in  the  rules. 

Lemma  2.6  In  the  semantics  C  of  Figure  2.2,  for  any  terms  M  and  AT,  the  following 
weakening  and  substitution  principles  hold: 

£[M](p)  =  £[A/](p\,r)  ifx  <t  FV(M ) 

£[M{M'/z}](p)  =  £[M](p[I^£[M'](p)]) 

Proof.  Routine,  by  induction  on  M.  ■ 

Given  this  lemma,  the  verification  of  the  following  equations  is  straightforward. 

Congruences,  substitutions  By  the  denotational  assumption,  our  notion  of  equival¬ 
ence  is  inherently  a  congruence  wrt.  all  the  term  constructors  of  the  language.  We  also 
have  general  principles  of  closure  under  weakening  and  substitution: 

r  b  M  =  AT  :a  Y,  x  :  ax  h  M  =  AT  :a  Y  b  Af  =  M[  :  ay 

r..r:n,  .1/  ,\T  :  n  r  h  .!/{.!/ ,/./■}  =  Al’{Al[/x}  :  a 

which  follow  directly  from  Lemma  2.6: 

£[M](p)  =  C{M\{P  \  *)  =  TIM'Kp  \  x)  =  ClM'Kp) 

£[M{M!/4](p)  =  C[M}{p[x^C[MTi{p)})  =  C,[M%p[x^£[M[}{p)]) 

=  C[M' {M[  /  x}\{p) 

Natural  numbers 

F  h  M~  :  a  T,  x:  t  h  Als  :  a  Y  h  M  :  t  F  h  M~  :  a  F,  x:  l  h  Ms  :  a 
F  h  ifz  (z,  Mz,  x.  Ms)  =  Mz  :  a  F  h  ifz  (s  M,  A Iz,  x.  Ms)  =  Ms{M/x}  :  a 

Y  h  M  :  l  T,  x:  t  h  AT  :  a 
r  h  ifz  (A/,  AT {z/x},  x' .  AT {s  x' / x})  =  M'{M/x}  :  a 


Unit  type 

r  h  M  :  1 
r  h  M  =  ()  :  1 

(1  is  a  terminal  object).  Note  that  this  equation  means  that  there  is  only  one  value  of 
type  1;  there  may  well  be  different  computations  of  that  value,  i.e. ,  terms  of  type  °1. 
Already  in  the  partiality  case  there  are  two  such  closed  terms:  termination  (°())  and 
divergence  (_L»i). 
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Products 


r  b  Mi  \ai  F  b  M2  :  oi2 
r  b  fst  {Mi,  M2)  =  Ml  :  Oi 


(■ +symm ) 


r  b  M  :  O'!  X  «2 

r  b  (fst  M,  snd  M)  =  M  :  oq  X  o2 


r  b  Mi  :  ft  F  b  m2  :  &  rbM:A^2 

r  b  fst  (Ml,  M2)  =  Ml  :  Pi  (  symm>  r  b  (fst  M,  snd  M)  =  M  :  ft  *  ft 

(Both  are  products  in  the  categorical  sense.)  Although  in  the  predomain  semantics  the 
two  notions  of  products  are  interpreted  by  the  same  object,  we  do  not  actually  require 
this  in  general. 


Sums 

T  b  M  :  ai  r,  x\\  Qi  b  Mi  :  a  F,  x2:  o2  b  M2  :  01 
r  h  case(in|  M,Xi.Mi,x2.M2)  =  Mi{M/xi}  :  a 

r  b  M  :  oq  -h  o2  T,x:  oq  “l-  o2  b  M  :  0 
T  b  case  (M,  xi.M'{  ini  aq/ft},  x2.M'{  inr  x2/x})  =  M'{M/x}  :  a 

(Sums  are  coproducts  in  the  categorical  sense.)  Verification  of  the  first  law  is  immediate, 
given  Lemma  2.6.  For  the  second,  we  rely  on  the  fact  that  C{M](p)  must  be  a  value 
of  the  form  (*,&);  the  equation  would  not  be  sound  if  +  were  interpreted  by,  e.g.,  a 
separated  sum  and  M  denoted  a  diverging  computation.  A  useful  consequence  of  the 
above  equations  is  that  for  any  h  (not  necessarily  denoting  a  strict  function), 

h  (case  (M,  .7.q..l/|,,r2..l/2))  =  h  (case  (x,  aq.Mi,  x2.M2)){M/x} 

=  case  (M,  Xi.h  (case  ( ini  x\,  X\.Mi,  x2.M2)),  x2.h  (case  ( inr  x2,  xi .AR,  x2.M2))) 

=  case  ( M,  xi .  h  ilft  ,x2.h  M2 ) 

Function  space 

T,  x:  a  b  Mi  :  P  T  b  M2  :  a  T  b  M  :  a  — >■  p 

V  ■  ( A./  " .  ,\ / 1 )  ,\/2  ,\  1/ { .1  / i  j.r )  :  i  F  b  [\x  .Mx]  M  :  0  >  P 

(Categorically,  a  — )■  p  is  an  exponentiation  of  a  and  ft  but  we  do  not  require  existence 
of  exponentiations  with  arbitrary  codomain  types,  so  the  category  of  types  and  terms  is 
not  quite  a  ccc.) 


Computations 

r  b  Mi  :  r,  x :  &i  b  M2  :  °a2  T  b  M  :  °a 

T  b  (let°  x  <=  °Mi  in  M2)  =  M2{Mi/x}  :  °a2  T  b  (let°  x  4=  M  in  °x)  =  M  :  °a 

r  b  Mi  :  °oii  r, xi'.ai  b  M2  :  °a2  T, x2 : a2  b  M3  :  °o;3 
T  b  (let°  x2  <=  (let°  x\  <=  Mi  in  M2)  in  M3)  =  (let°  Xj  <^=  Mi  in  let°  x2  <=  M2  in  M3)  :  “03 

Each  of  these  corresponds  directly  to  one  of  the  monad  equations  governing  the 
ambient-effect  monad  (T,  ft0  ).  For  example,  for  the  first  one  we  verify: 

£[letf  x  <=  in  MJ(p)  =  (Aa.£[M2](p[x  ^  0]))°(e(£[M,](p))) 

=  (A«.£[M2](p[*^a]))(,C[A:f1](p))  =  £[M2](p[i«£[M1](p)]) 


2. 1 .  THE  BASE  LANG  UAGE 


27 


Fixed  points 

r  •  fix,.!/  ,U(fix,  .U)  :  i 

This  suffices  for  evaluation,  but  for  more  general  formal  reasoning  we  will  need  additional 
properties;  the  details  of  this  are  covered  in  the  next  chapter.  (Actually,  none  of  the 
results  in  the  thesis  depend  on  the  fixed-point  equation  being  in  So,  so  in  principle  we 
could  safely  omit  it  without  affecting  correctness.) 

We  have  thus  established: 

Proposition  2.7  For  any  ambient-effect  monad,  the  predomain  semantics  C^r.s,,*)  a 
jnodel  of  So,  the  equational  theory  generated  by  the  inference  rules  listed  above. 

2.1.6  Encodings  of  implicitly-sequenced  languages 

In  actual  programming  languages  there  is  often  no  explicit  syntactic  or  typing  distinction 
between  values  and  general  terms.  Rather,  the  grammar  of  types  and  terms  is  of  the  form: 

a  ::=  l  |  1  |  a\  x  o2  |  0i  +  eg  |  0i  — >■  cr2 
E  ::=  x  |  z  |  sM  |  ()  |  (/•.')•,  /A)  |  fst  E  snd  E  |  ini  E  |  in rE 
|  cas e(E,  xi.Ei,  x2.E2)  |  A xa.E  \  E\E2  |  fix  if 

with  trivial  and  serious  computations  a  priori  occupying  the  same  type. 

Our  explicitly-sequenced  syntax  simplifies  formal  manipulation  of  programs,  but  it 
is  somewhat  inconvenient  for  actual  programming.  (However,  in  common  practice,  it  is 
relatively  uncommon  to  see,  e.g.,  applications  of  the  form  E\E2  where  one  or  both  of 
Ei  and  E2  themselves  have  effects;  in  particular,  evaluation  of  E\  only  very  rarely  has 
effects).  Nevertheless,  typical  programs  in  ML-like  languages  do  have  some  sequencing 
left  implicit,  and  it  would  be  too  burdensome  to  force  them  to  always  be  explicitly 
sequenced. 

Fortunately,  we  can  treat  the  more  compact  general  syntax  as  merely  shorthand 
for  explicitly-sequenced  terms,  with  programs  first  being  desugared  or  elaborated  into 
sequenced  form,  and  only  then  given  an  operational  or  denotational  semantics.  We 
present  two  such  elaborations,  leading  to  either  a  call-bv-value  (CBV)  or  a  call-bv-name 
(CBN)  interpretation  of  the  implicitly-sequenced  language. 

CBV  Translation  on  types.  If  a  is  a  type  of  the  CBV  language,  (a))v  is  a  type  of  L0. 


ur  =  1 
((i)v  =  1 

f>i  X  a2)v  =  (tfOr  x  ((a2))v 

t^i+^r  =  mv  +  (M)v 
((cq  (T2))V  =  !<R))V  °(M 


.V 
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Translation  on  terms.  If  T  b  E  :  a  in  the  source  language,  then  ((r))v  b  ((i?))v  :  °((ct))v 
in  L0: 


(OF 

((z))v 
is  E)Y 
((ifz  {E,Ez,x.Es)T 


((E1,E2))v 

{1st  EY 

((snd  EY 
{\n\EY 

((inr  EY 
{case(E1x1.E1,x2.E2)Y 
(XxCEY 
((EiE2Y 
(fi  x*EY 


°x 

°z 

let°  x  -<=  {EY  in  °(s‘r) 

let”  n  <=  (EY  in  ifz(n,  (( Ez)v,x .  { Es))v ) 

°<> 

let”  xi  <=  {EiY  in  let”  x2  •<=  {E2))v  in  °(xux2) 

let”  x  -<=  {EY  in  °(fst:r) 

let”  x  -<=  {EY  in  °(snd  x) 

let”  ;r  -<=  {EY  in  °(inl  x) 

let”  x  -<=  {EY  in  °( inr  x) 

let”  x  <=  {EY  in  case  (x,  x1.{E1))v,  x2.{E2Y) 

°(A  x**r.{EY) 

let”  f  <$=  {EiY  in  let”  a  <$=  {E2Y  in  fa 

let”  F  <=  {EY  in  ”(fix|ffJv  (A/.let”  f  <=  Ff  in  /')) 


where  for  the  CBV  fix,  a  must  be  a  functional  type,  so  that  (((t))v  is  a  computation-type. 
(We  can  actually  also  allow  it  to  be  a  product  of  computation-types,  if  in  the  context 
of  mutually-recursive  definitions  we  interpret  x  as  the  computation-product  X.)  The 
explicit  letjyjv  is  necessary  because  the  type  of  F  is  ((cr  — >■  cr))v  =  ((ct))v  — >■  °((cr))v. 

When  E  is  syntactically  a  value  V,  we  have  ((V'))v  =  °M  for  some  M.  Thus,  for 
example,  we  get  validity  of  beta-value  reduction  because 

(((A  x.E)VY  =  let”  /  4=  ((A  x.EY  in  let”  a  <=  {V))v  in  fa 

=  let”  /  X=  °(Xx.  {EY)  in  let”  a  <=  °M  in  fa  =  (Ax.  { E))V)M  =  ( E))v{M/x } 

=  (E{v/x}r 

Similarly,  in  general  we  have 


((A x.ExY  =  °(Ax.  let”  /  X=  (E))v  in  f  x)  =?  (E))v 


but  when  {EY  =  °M  for  some  M,  the  equality  does  hold. 


CBN  A  CBN  interpretation  gives  a  language  essentially  identical  to  PCF  with  product 
and  sum  types.  The  type  translation  is  now: 


cor  = 

((ir  =  i 

((ai  x  a2))n  =  ((ax))11  X  ((a2))n 

((a1  +  a2)r  =  OC^ir  +  C^D 
(<7i-><72r  =  (ror^  (Mr 


2.2.  MONADS  IN  A  COMPUTATIONAL  SETTING 
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Since  the  interpretation  of  every  type  is  computational,  we  can  form  exponentials  between 
any  pair  of  types  exponentials,  and  thus  the  source  language  forms  a  ccc.  When  the 
elaboration  is  composed  with  our  predomain  semantics,  every  type  is  interpreted  by 
a  (proper)  domain;  in  fact,  for  a  partiality  semantics,  this  gives  exactly  the  standard 
domain-theoretic  model  of  PCF. 

Translation  on  terms.  If  T  h  E  :  a  in  the  source  language,  then  ((T))n  b  (E)n  :  ((o'))11 
in  L0. 


(XF 
(zF 
is  EF 
(ifz  (E,Ez,x.Ea)F 


i(Ei,E2)F 
(fst  EF 

((snd  EF 
((ini  EF 

(( inr  EF 

{case  {E^xx. Ei,  x2.E2)F 
(XxAEF 
{EiE2F 
((fixff  EF 


let°  x  -<=  {EF  in  °(sx) 

letc<rr  C^))n  in  'fz(ni{EzF,x-{EsF{°x/x}) 

0 

{{EiF,  {e2F) 
fst  {EF 
snd  {EF 
“(ini  {EF) 

°( inr  {EF) 

letj^jn  X  <=  {EF  in  case (ar, Si.((^i))n, x2.{E2F) 

Xx^r.{EF 

{EiFiEiF 

fix«»)n  {EF 


where  we  now  have  fixed  points  at  all  source  types,  including  t.  Note  also  that  numbers 
are  still  represented  by  a  flat  domain  (as  opposed  to  the  lazy  natural  numbers ,  which  also 
include  partially-defined  values,  such  as  s_L). 


2.2  Monads  in  a  computational  setting 

In  this  section,  we  present  a  formal  definition  of  monads,  suitable  for  a  language  that 
already  has  a  notion  of  ambient  effects.  This  definition  is  phrased  in  terms  of  few  basic- 
concepts,  which  we  need  to  introduce  first. 

2.2.1  A  framework  for  effects 

The  ultimate  goal  of  the  line  of  research  presented  here  is  a  framework  for  computational 
effects  which  makes  it  possible  to  describe  effects  in  a  modular  way.  Specifically,  we  want 
the  ability  to  add  effects  incrementally,  the  resulting  language  is  specified  by  a  sequence 
of  definitional  translations,  each  one  of  which  “translates  away”  one  level  of  effects.  For 
example,  we  can  have  a  language  with  exceptions  and  state,  specified  as  a  composition 
of  an  exception-passing  and  a  state-passing  transform. 

For  now,  however,  we  only  consider  the  two-level  case,  with  a  notion  of  ambient  effects 
(possibly  already  a  combination  of  several  primitive  ones),  specified  by  the  “semantic” 
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monad  T  used  in  the  denotational  semantics);  and  a  focus  effect,  specified  by  a  “syntactic” 
monad  T. 

In  order  to  define  the  notion  of  a  monad  that  interacts  in  a  suitable  way  with  ambient 
effects,  we  need  some  amount  of  structure  in  the  language.  The  following  provides  what 
we  will  need: 

Definition  2.8  We  say  that  a  language  ( L ,  £)  is  a  computational  lambda-language  (ell) 
if  it  has  a  class  of  computation  types  0,  forming  a  (not  necessarily  proper)  subset  of  all 
types  a,  and  with  the  following  properties: 

•  There  are  coinputations  at  any  type,  and  the  set  of  computation-types  is  closed 
under  finite  products  and  function  spaces  (with  arbitrary  domain): 

a  type  //  ctype  02  ctype  a  type  0  ctype 

°«  ctype  1  ctype  0i  ^  02  ctype  a  — >■  0  ctype 

We  write  b^  °  type  and  b^  0  ctype  for  types  over  a  set  of  type  variables  A,  but 

do  not  require  C  to  assign  any  meaning  to  such  types  when  A  is  nonempty. 

•  The  syntax  L  includes  at  least  the  following  terms  and  term  constructors: 

(x:  a)  G  T  T  b  M  :  a  F  h  Mi  :  °a  T,  x:  a  b  M2  :  0 
r  •  x  :  a  r  M  :  n  h  •  let.  ,.  x  •<  ,l/;  in  M,  :  3 

(that  is,  we  have  variables,  computation-inclusions,  and  a  generalized  let/,  together 
with  the  term  constructors  for  products  and  function  spaces.  Again,  we  write  T  b^ 
M  :  a  for  a  term  over  A,  not  necessarily  given  a  meaning  by  C. 

•  In  the  semantics  C,  the  following  equations  hold  (between  type-closed  terms): 

r  b  Mi  :  a  Y,x:a  b  M2  :  0  T  b  M  :  °a 

T  b  (let/  x  <=  °M\  in  M2)  =  M2{M\ / x\  :  0  f  b  (let°Q  x  <=  M  in  °x)  =  M  :  "or 


r  b  M\  :  °«i  r,  xi'.oii  b  M2  :  °a2  T,  x2:  a2  b  M3  :  0 
T  b  (let/  x2  <=  (let°Q2  xi  <=  Mi  in  M2)  in  M3) 

=  (let/  x  1  4=  Mi  in  let/  x2  <^=  M2  in  M3)  :  0 

together  with  the  congruence  and  substitution  rules,  as  well  as  the  axioms  for  unit, 
products,  and  functions  (as  listed  in  Section  2.1.5).  And  finally,  the  generalized  let 
must  satisfy  (not  necessarily  directly  by  definition)  the  equations  in  Definition  2.0. 

For  example,  in  any  ell,  for  every  type  a,  there  exists  a  (computation- )type  aM-aM- 
°a  x  °a.  Note  that  this  is  a  slightly  stronger  requirement  than  Moggi’s  T-exponentials 
[Mog89],  which  only  guaranteed  existence  of  all  function  spaces  of  the  form  o ,  — >■  °a2. 

A  weaker  notion  would  be  to  take  the  computation  types  to  be  exactly  the  set  of 
types  of  the  form  °a.  However,  requiring  computation-types  to  be  closed  under  products 
and  (especially)  function  spaces  will  allow  us  to  give  a  uniform  treatment  of  definable 
computational  effects. 


2.2.  MONADS  IN  A  COMPUTATIONAL  SETTING 
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Proposition  2.9  Our  base  language  (with  any  model  C  satisfying  the  equations  in  Sec¬ 
tion  2.1.5)  can  be  organized  as  a  ell  by  defining  let/3  inductively  as  in  Definition  2.f. 

Proof.  We  only  need  to  verify  that  the  equational  properties  of  the  generalized  let  hold 
for  the  definition.  The  proof  is  a  simple  induction  on  3.  We  show  two  sample  cases;  the 
others  are  very  similar. 

let^iX^o  x  •<=  °Mi  in  M2  =  (let^  x  <^=  °M\  in  fst  M2,  let^.,  x  <^=  °M\  in  snd  Mf) 

=  (fstM2{Mi/a:},  snd  M2{m[/x})  =  (fst  M2,  snd  M2){M1/x}  =  M2{M1/x} 

let°a_^  x2  <=  (let°Q2  x\  -/=  Mi  in  M2)  in  M3 

=  Aa.let°a  x2  •<=  (let°ao  x \  •<=  Mi  in  M2)  in  M3  a 
=  Aa.let°fl  x\  z=  M\  in  let°3  x2  z=  M2  in  M3a 
=  Aa.let°3  x\  •<=  Mi  in  (Aa.let°a  x2  -4=  M2  in  Ms  a)  a 
=  Aa.let°3  x\  <s=  Mi  in  (let))_^  x2  •<=  M2  in  Ms) a 
=  x  1  ^  Mi  in  let°a_^  x2  <=  M2  in  M3 


Other  ways  of  constructing  computation-types  may  be  possible,  depending  on  the 
actual  set  of  types  available.  For  example,  in  a  language  with  explicit  polymorphism,  it 
seems  natural  to  take  ft  ::=■■■  \  Va.  ft,  with  the  generalized  let  extended  accordingly. 

For  lack  of  a  better  name,  we  say  that  a  computational  A-language  is  effect-free  if 
a  and  °a  are  actually  the  same  type  (with  °M  =  M);  in  this  case,  the  ell  requirements 
degenerate  to  those  of  a  ccc.  But  effect-freeness  should  not  be  confused  with  existence 
of  a  type  a  — >■  a1  (with  associated  abstraction  and  application  operations)  for  all  a'  -  we 
can  have  the  latter  without  the  former. 

(We  do  not  actually  work  with  any  concrete  effect-free  languages;  the  concept  is 
mainly  used  to  show  that  various  definitions  and  results  reduce  to  their  more  familiar 
counterparts  in  the  existing  work  on  monads  for  computational  effects.) 


Remark  2.10  The  essence  of  a  generalized  let  at  a  computation-type  ft  can  be  expressed 
simply  as  existence  of  the  function 


£3  :  ° ft  — >■  ft  —  Am.  let))  x  <=  in  in  x 


satisfying  the  equations 

x:  ft  b  (g  (°x)  =  x  :  ft 

and 

m:  °{°ft)  b  C/3  (let°  x  <t=  m  in  x)  =  C/3  (let°  x  <=  m  in  °{(px))  :  ft 

(In  category-theoretic  terms,  this  says  that  C/3  is  the  structure  map  of  an  algebra  (ft,() 
for  the  monad  underlying  °  [ML71,  VI. 2].)  Specifically,  given  such  a  function,  we  can 
define  a  generalized-let  operator  by 


let)/  x  <£=  Mi  in  M2  =  C/3  (let°  x  <=  Mi  in  °M2) 

However,  the  generalized-let  formulation  is  more  convenient  to  work  with,  its  equational 
properties  being  a  natural  generalization  of  the  existing  let,  as  formalized  in  Defini¬ 
tion  2.8.  Remember  also  that  our  generalized  let  (or,  equivalently,  C)  is  characterized 
uniquely  by  Definition  2.4.  ■ 
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Among  other  applications,  the  generalized  let-operation  can  be  used  to  define  a  simple 
“effect-theoretic”  generalization  of  strictness,  which  in  turn  plays  a  key  role  in  the  defin¬ 
ition  of  layerable  monads. 

2.2.2  Rigidity 

Definition  2.11  We  say  that  a  term  Y  b  M 
computation-types  0  and  0'  if 

T,  m:  °0  b  M  (let),  x  <=  m  in  x) 

We  write  this  as  F  b  M  :  (3  -A-  / 3 ' . 

Rigidity  is  a  purely  equational  property;  as  such,  we  distinguish  between  provable  rigidity 
(i.e. ,  when  the  above  equation  is  derivable  in  an  equational  theory)  and  semantic  rigidity 
(when  the  equation  holds  in  a  model);  the  former  implies  the  latter. 

As  an  immediate  consequence  of  the  definition,  we  get: 

Lemma  2.12  An  application  of  a  rigid  function  can  be  “moved  through ”  an  arbitrary 
let-binding: 


:  (3  — >■  (3'  in  a  ell  is  a  rigid  function  between 
=  (let),,  x  <=  m  in  M x)  :  0' 


1  —  A/  :  .3  r>  ;3'  Y  b  M1  :  °a  Y,  x:aY  M2:  0 
V  M(\et)x  <  ,\h,  in  M,)  (let.),,  .r  <  M:mMM,):l' 

(i.e.,  the  above  is  derivable  in  £0  and  hence  true  in  any  model.) 

Proof.  Simple  verification: 

M  (let),  x  <=  Mi  in  MA  =  M  (let«  x  <=  Mi  in  let",  y  <=  °M2  in  y) 

=  M  (let;  „  «=  (le^b  «=  M,  in  ‘M2)  in  „) 

=  (M  (let),  y  m  in  y)){(let°j3  x  <=  Mi  in  °M2)/m } 

(let),,  y  <=  m  in  M y){(let°„  x  <=  Mi  in  °M2)/m } 

=  let"),  y  <t=  (let".,,  x  <=  AR  in  °M2)  in  My 

=  let),,  x  y=  Mi  in  let",,  y  <t=  °M2  in  My  =  let),,  x  <=  M\  in  M M2 
where  f  marks  the  application  of  rigidity  of  M.  ■ 

In  particular,  for  any  M'  :  °a  and  rigid  M  :  °a  — >■  W, 

M  M'  =  M  (let°  x  <=  M'  in  °x)  =  let"  x  <t=  AT  in  M  (°x) 

Operationally,  this  says  that  an  argument  to  a  rigid  function  can  be  evaluated  before 
the  call  and  the  result  coerced  into  a  trivial  computation,  instead  of  the  nominal  CBN 
evaluation  for  parameters  of  °-tvpe.  This  is  usually  a  property  associated  with  strictness. 
And  indeed  we  have 

Proposition  2.13  In  the  predomain  model  (for  any  T)  of  our  base  language,  a  rigid 
function  is  necessarily  strict.  In  the  particular  case  of  the  partiality  semantics,  the  con¬ 
verse  also  holds,  i.e.,  any  strict  function  is  rigid. 
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Proof.  First,  it  is  easy  to  check  the  following  equational  reasoning  principle: 

T,  x:  a  b  M  :  3 

I  h  (let^  x  <  Ma  in  M)  =  Eg  :  3 

(because  for  any  /,  /°  is  strict,  and  £[_Ljg](p)  =  T^j).  Now,  let  h  :  3  — >■  3'  be  a  rigid 
function.  Then 

h-Lp  =  h(let°g  x  <=  _L"i  in  Eg)  =  let^,  x  <=  _L°i  in  hEg  =  Eg* 

Conversely,  let  h  be  strict  and  let  rn  :  °/3.  When  T A  =  A±,  there  are  only  two 
possibilities  for  m: 

•  rn  =  l_°p.  Then 

h(let°p  x  <=  m  in  x)  =  h(let°g  x  <=  Mg  in  x)  =  h±g  =  _Lgi 
=  letg,  x  <=  Mg  in  hx  =  let^,  x  Mm  in  h x 

•  m  =  °b  for  some  b  :  3' 

h  (let^  x  <=  m  in  x)  =  h  (let^  x  <=  °b  in  x)  =  hb  =  letg,  x  <=  °b  in  hx 
=  let^,  x  <=  m  in  hx 


In  general,  a  function  is  rigid  if  it  uses  its  argument  exactly  once,  and  before  any  other 
serious  computation.  But  in  the  particular  case  of  partiality,  a  function  like  h  =  Xx.  _L 
(=  Xx.  let”  y  <=  x  in  _L  in  the  model)  also  qualifies  as  rigid,  even  though  it  does  not 
explicitly  reference  its  argument. 

It  is  easy  to  check  that  identity  and  composition  of  two  rigid  functions  are  rigid:  so 
are  fst,  snd,  A/,  fa  for  any  a,  and  Aa:.let0  a  <=  x  in  fa  for  any  /.  Likewise,  if  fi  and  /2 
are  rigid,  so  is  Xx.  (J\  x.  /21),  and  if  fa  is  rigid  for  every  a,  so  is  Xx.  Xa.  f  ax.  These  are 
well-known  properties  of  strictness,  but  also  hold  for  general  rigidity. 

In  the  effect-free  case  (°a  =  a),  every  function  is  trivially  rigid. 

Remark  2.14  We  can  give  an  alternative,  equivalent  characterization  of  rigidity.  There 
is  a  natural  functorial  action  of  °,  mapping  a  function  /  :  3  — >■  3'  to 

/**  :  °3  — >■  °3'  =  Am.  let”  x  <=  m  in  °(f  x) 

Further,  recall  from  remark  2.10  that  for  any  3,  we  can  define 

(g  :  ° 3  — >■  3  =  Am.  leti  x^m  in  x . 

Then  a  function  /:/?—>■  3'  is  rigid  iff  Qg*  o  f$  =  f  o  (g  (i.e. ,  if  /  is  a  morphism  of  the 
corresponding  “-algebras),  because 

[fgi  o  p)m  =  (gt  (let°  x  <=  m  in  °(fx))  =  let^,  y  <=  (let°  x  <=  m  in  °{fx))  in  y 
=  let^,  x  <=  m  in  letg/  y  <=  °{f  x)  in  y  =  letly  x  <=  rn  in  f  x 

while 

(f0(y)m=  f{let°g  x  <=  m  in  1). 
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2.2.3  Definable  monads 

The  notion  of  a  monad  in  a  language  (L,  C)  consists  of  both  a  syntactic  and  a  semantic- 
aspect.  Syntactically,  we  exhibit  a  type  constructor  T-  and  term  families  r]  and  -*  in 
L.  Semantically,  we  establish  that  certain  equational  properties  hold  among  these  terms 
in  jC  (but  not  necessarily  in  any  particular  equational  theory  for  L ).  The  separation 
is  important  -  we  will  eventually  have  to  consider  interpretations  of  the  r]  and  *  in  a 
semantics  where  they  do  not  necessarily  satisfy  the  monad  laws. 

When  Ha  ol  type  is  a  type  over  A  in  L  and  9  is  a  substitution  of  (closed)  L-types  for 
variables  in  A,  a{9}  is  itself  a  (closed)  type  of  L.  In  particular,  a  type  constructor  F a  =  a 
(where  a  may  occur  in  a)  can  be  identified  with  a  type  schema  b{aj  a  type.  Analogously, 
given  a  term  T  b  M  :  a,  9  determines  a  (type-closed)  L-term  T{0}  b  M{9}  :  a{9}. 

We  can  now  give  a  formal  definition  of  a  monad  (in  the  Kleisli-triple  formulation): 

Definition  2.15  Let  L  be  a  signature  of  a  ell.  A  monad-triple  T  in  L  consists  of  the 
following  iteins: 

•  A  cojnputation-type  constructor,  b{aj  T a  ctype.  We  write  Ta  for  Ta{a/a). 

•  A  term  family  of  unit  functions,  given  as  instances  of  a  term  b{aj  r]a  :  a— »Ta.  We 
write  T)n  for  i]a{u/ a}. 

•  A  term  family  of  extension  operators,  /:  ai  — >■  T a,2  b{aija2}  /*  :  Tai  -^T&2  (strictly 
speaking,  type-indexed  as  above,  but  we  always  omit  the  type  indices). 

Such  a  triple  is  an  actual  monad  in  the  ell  ( L ,  C)  if  in  C  the  following  equations  hold  at 
all  closed  type  instances: 

0.  f:  cti  — >■  Ta2  b  /*  :  Tcki  -A  Ta2. 

1.  f:  O'!  Ta2  b  /*  o  r)ai  =  f  :  ay  — >  Ta2 . 

2.  b  //*  =  id^a  :  Ta^Ta. 

3.  f:  ai  ->■ Ta2,g :  a2  ->■  Ta3  b  f*  o  g*  =  (f*  o  g )*  :  Tax  ->■  Ta3. 

(Note  that  (0)  is  an  equational  condition  like  the  others,  because  of  its  expansion  in 
Definition  2.11.  Conditions  (0-3)  also  cover  equations  between  non-variable  terms,  such 
as  (r]M2)  =  M\M2,  because  of  closure  under  substitution  of  terms  for  variables.) 

Actually  the  above  definition  is  more  akin  to  that  of  a  7nonad  constructor  than  of  a 
simple  monad;  the  necessary  information  for  composition  is  implicit  in  the  representation 
of  the  monad  in  the  computational  language.  Nevertheless,  we  will  refer  to  it  as  a  monad 
over  C,  since  that  is  where  the  monad  laws  are  required  to  hold  -  as  opposed  to  being- 
provable  in  some  equational  theory  for  L.  Of  course,  showing  the  monad  laws  in  the 
equational  theory  is  sufficient  to  establish  them  for  a  model  of  that  theory. 

Note  that  condition  (0)  only  makes  sense  because  both  Toy  and  Ta2  are  required  to 
be  computation  types.  When  C  is  effect-free,  the  rigidity  requirement  is  vacuous,  and 
the  definition  reduces  to  that  of  an  ordinary  monad. 

Although  it  is  important  for  our  concrete  language  that  rigidity  implies  strictness, 
the  rigidity  requirement  for  f  *  is  not  merely  present  for  domain-theoretic  reasons;  it 
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is  crucial  for  composing  effects  in  general,  and  would  be  present  even  in  a  purely  set- 
theoretic  formulation  of  composable  monads  in  a  setting  without  general  recursion.  In 
practice,  natural  monad  extensions  always  seem  to  be  rigid  anyway. 

Example  2.16  (Identity)  Perhaps  the  simplest  possible  monad,  definable  in  any  ell,  is 
given  by: 

Ta  =  °a,  7]  =  Xa.  °a,  f*  =  A  t.  let°  a  <^=  t  in  fa 

The  verification  of  the  monad  laws  is  straightforward.  The  identity  monad  is  actually  a 
degenerate  case  of  many  others:  for  example,  we  obtain  it  by  specializing  the  exception 
monad  below  to  y  =  0  (a  type  with  no  values,  hence  no  possibility  of  raising  an  exception) 
or  the  state  monad  to  a  =  1  (a  type  with  one  value,  hence  an  information-free  state). 


Example  2.17  (Exceptions)  Let  y  be  some  fixed  type  of  exception  names  (exn  in 
SML).  We  then  obtain  a  monad  by: 

Ta  =  °(a  +  y),  p  =  A  a.  °( ini  a),  f*  =  At.  let°  v  <=  t  in  case  (v,  a.f  a,  e.°(  inr  e)) 

For  completeness,  we  show  the  complete  verification,  since  it  is  slightly  more  involved 
than  for  an  exception  monad  over  an  effect-free  language: 

f*  (letyQi  i<^mini)  =  let°  v  <=  (let°^Qi+^  x  <=  m  in  x)  in  case  (v,  a.f  a,  e.°(  inr  e)) 

=  let”  x  4=  m  in  let”  v  4=  x  in  case  (v,  a.f  a,  e.°(  inr  e))  =  let^Qo  x  •<=  m  in  f*x 

f*  or]  =  A  a.  f*  (rj  a)  =  Aa.let"  v  <=  °( ini  a)  in  case  (v,a.f  a,e.°(  inr  e) ) 

=  A  a.  case  ( ini  a,  a.f  a,  e.°(  inr  e))  =  A  a.  fa  =  f 

r]*  =  At.let°  v  <=  t  in  case  ( v ,  a.°(  ini  a),  e.°(  inr  e))  =  At. let"  v  <=  t  in  °v  =  Xt.t  =  id 

g*  of*  =  Xt.g*  (/*  t)  =  A  t.g*  (let°  v  <=t  in  case  (v,  a.f  a,  e.°(  inr  e))) 

=  At.  let°  v  <=  t  in  g*  (case  (v,  a.f  a,  e.°(  inr  e) ) ) 

=  At.  let°  v  <=t  in  case  (v,  a.g*  (/  a),  e.g*  (°( inr  e))) 

=  At.  let"  v  <=t  in  case  (v,  a.g*  (/  a),  e.let°  w  <=  °( inr  e)  in  case  (w,  b.gb ,  e.°(  inr  e))) 

=  At.  let"  v  <=t  in  case  (v,  a.g*  (/  a),  e.case  ( inr  e,  b.gb,  e.°(  inr  e))) 

=  At.  let"  v  <=t  in  case  (v,  a.g*  (/  a),  e.°(  inr  e))  =  (A  a.g*  (f  a))*  =  (g*  of)* 

(Note  that  the  type  and  term  constructors  are  in  the  image  of  the  CBN  translation; 
thus  exceptions  also  form  a  monad  in  a  language  like  Haskell,  where  the  language-level 
sum  type  is  actually  a  “separated  sum”  in  domain  terminology.)  ■ 

Example  2.18  (State)  Let  a  be  any  type.  Then  the  a -state  monad  is  defined  by: 

Ta  =  a  — t  °(cr  x  a),  r]  =  Xa.  Xs.°(a,  s),  f*  =  At.  As.  let°  (a,  s')  <=  t  s  in  fas' 

Again,  the  verification  is  fairly  simple: 

f*(let°Tai  x^m  in  x)  =  As. let"  (a, s')  4=  (let^_^Qi  x  <=  m  in  x)  s  in  fas' 

=  As.  let"  (a,  s')  <=  (let°(QlX0.)  j^=minis)  in  fas' 

=  As.  let"  x  <=  m  in  let"  (a,  s')  4=  x s  in  f  as'  =  As.  let"  x  <=  m  in  f*  x s 
=  letyQ2  x  <=  m  in  f*  x 
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f  or/  =  Xa.f*  (j]a)  =  Xa.  As.  let°  (a,  s')  •<=  [As.  °(a ,  s)]  s  in  f  as' 

=  A  a.  As.  let°  (a,  s')  <=  °(a,  s)  in  /  as'  =  A  a.  As.  /  (fst  { a,s ))  (snd  (a,s))  =  Xa.  Xs.  f  as 
=  Xa.f  a  =  f 

r]*  =  At.  As.  let"  (a,  s')  <=ts  in  [Aa.  As.  °(a,  s)]  as'  =  At.  As.  let"  (a,  s')  <=ts  in  °(a,s') 

=  At.  As.  let"  p  <=ts  in  °p  =  At.  As.ts  =  A t.t  =  id 

g*  o  f*  =  At.  g*  ( f*t )  =  At.  g*  (As. let"  (a,  si)  ■ <=ts  in  f  as\) 

=  At.  As.  let"  (6,  s 2}  -4=  (let"  (a,  si)  y=  t s  in  f  as\)  in  gbs 2 
=  At.  As.  let"  (a,  si)  -4=  is  in  let"  (b,  s 2}  •<=  f  asi  in  gbs? 

=  At.  As. let"  (a,  si)  -£=  ts  in  g*  (f  a)s\  =  At.  As. let"  (a,  si)  •<=  ts  in  [Xa.g*  (f  a)]as  1 
=  (Xa.g*(fa)y  =  (g*of)*  ' 


Although  most  practically  useful  monads  over  (Lq,jC)  are  actually  monads  in  any 
model  of  the  equational  theory  So,  there  are  two  important  reasons  to  only  require  the 
monad  laws  to  hold  with  respect  to  specific  interpretations.  First,  since  the  monad 
components  may  be  defined  using  fix,  it  can  be  arbitrarily  hard  to  show  that  a  given 
monad-triple  is  actually  a  monad;  certainly  So  alone  will  not  always  be  sufficient.  We 
only  need  So  to  validate  a  few  equational  properties  that  will  be  used  frequently  in  the 
proofs  later;  the  results  do  not  rely  on  the  monad  laws  for  particular  monads  being 
provable  in  So- 

The  second,  and  more  fundamental,  reason  is  that  certain  very  useful  notions  of 
computation  do  not  actually  form  monads  in  the  presence  of  arbitrary  ambient  effects. 
Perhaps  the  best  known  such  example  [KW93]  is  the  list  monad  Ta  =  °(a  list),  used 
to  model  nondeterminism.  It  turns  out  to  only  be  a  monad  if  the  ambient  effects  are 
commutative ,  i.e. ,  if  the  equation 

let°  xi  A=  Mi  in  let°  x2  <=  M2  in  M  =  let°  x2  M2  in  Iet°  aq  M\  in  M 

(where  neither  ay  occurs  free  in  an  Mj)  holds  in  C.  Partiality  satisfies  the  above  equation, 
but  many  other  possible  notions  of  ambient  effects,  such  as  state  or  continuations,  do  not. 
Other  examples  of  “fragile”  monads  require  the  ambient  effects  to  also  be  idempotent ,  a 
property  shared  by  few  effects  other  than  partiality. 

Thus,  distinguishing  between  satisfaction  of  the  monad  laws  in  the  equational  theory 
and  in  a  specific  model  (such  as  the  partiality  semantics)  makes  our  results  applicable  to 
list-like  monads  as  well  as  the  “robust”  ones  (such  as  exceptions  or  state),  that  satisfy 
the  monad  laws  for  any  notion  of  ambient  effect. 

Let  us  finally  note  that  given  a  semantics  that  also  assigns  a  meaning  to  type-open 
types  and  terms,  a  stronger  definition  of  monad  is  possible: 

Definition  2.19  When  T  is  a  monad  in  ( L ,  C)  where  C  is  the  predomain  interpretation 
for  any  T,  T  is  said  to  be  uniform  if  its  equations  also  hold  for  type- open  terms.  That 
is,  for  each  of  the  four  monad  laws  T  h  M\  =  M2  :  a  in  Definition  2.15,  if  we  allow  the 
types  and  terms  to  contain  type  variables  from  A,  6  assigns  a  cpo  to  each  a  €  A,  and 
pxi  G  £[ai.,;]]0  for  each  (xp  afi  G  F  then  C\Mi\°(p)  =  C\M2\°(p)  as  elements  of  C,\a\e . 

We  can  then  state  the  simple  consequence: 
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Proposition  2.20  Let  T  be  a  uniform  monad  in  the  predomain  semantics  (for  some 
notion  of  ambient  effect).  Then  the  following  determines  a  new  ambient- effect  monad  in 
the  sense  of  Definition  2.2: 

TA  =  £[Taf^  fA  =  C{rlaf^A(.)  f  =  £lx*r~M^A2(»lx^f]) 

Proof.  We  first  note  that  because  computation-types  were  interpreted  as  pointed 
epos  by  C,  TA  is  pointed  as  required.  Similarly,  because  arrow-types  are  interpreted  as 
continuous-function  spaces,  Cl  and  /°  are  continuous;  and  because  £[M]  is  a  continuous 
function  from  environments  to  values,  so  is  the  mapping  /  i— >■  /°.  Finally,  by  Proposi¬ 
tion  2.13,  we  get  strictness  of  /°  from  rigidity  of  x*.  The  verification  of  the  monad  laws 
is  also  straightforward  given  uniformity  of  T.  ■ 


However,  usually  there  is  no  need  to  modify  the  semantic  characterization  of  ambient 
effects  explicitly;  we  can  define  a  language  with  a  new  notion  of  ambient  effects  via 
iterated  monadic  translation,  in  which  case  it  is  sufficient  for  the  monad  laws  to  hold 
only  for  type-closed  instances. 

2.3  Extending  the  language  with  effects 

2.3.1  The  monadic  translation 

We  now  show  how  a  monad  in  a  language  allows  us  to  define  a  new  language  with  a 
richer  set  of  computational  effects. 

Definition  2.21  Let  T  =  (T,  77, -*)  be  a  7nonad-triple  over  a  ell  signature  L.  Then  the 
signature  LT  consists  of  L  extended  with  a  new  computation-type  constructor, 

\~ a  «  type 
Fa  '«  ctype 


and  new  term  constructors: 


T  h  M\  :  °a i  T,  x:  a\  h  M2  :  '«2 
T  h  let°  x  <=  Mi  in  M2  :  '«2 

F  h  M  :  a  r  h  Afi  :  'ai  T,  x:  a  h  M2  :  'a2 
F  h  1 M  :  Vv  F  h  let'  x  -t=  M\  in  M2  :  '«2 

F  h  M  :'a  F  h  M  :  Ta 
h  •  [.!/]  :  I  n  r  h  ii{M)  :  'a 

(Note  that  we  overload  the  syntactic  construct  let”  to  represent  two  distinct  term  con¬ 
structors:  the  existing  one,  where  M2  :  °«2  and  the  new  one  defined  above,  where  M2  :  'a2. 
It  will  always  be  clear  from  context  which  one  is  meant.) 
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There  are  now  two  basic  notions  of  computation:  the  original  °a  (e.g.,  partiality) 
and  'a  which  also  includes  T-effects  (e.g.,  raising  exceptions).  As  before,  the  set  of 
computation-types  is  closed  under  products  and  function  spaces. 

Because  we  have  extended  the  signature  (rather  than  merely  the  unstructured  set  of 
types),  every  type  constructor  of  L  is  still  a  type  constructor  of  LT .  In  particular,  for 
any  LT-type  a,  Ta  is  a  well-formed  LT-tvpe.  Generalized  let  (still  for  binding  results  of 
“-computations)  is  also  definable  at  all  computation-types,  with  the  new  clause  for  letTa 
using  the  mixed-level  let. 

Reflection  (/ u(M ))  and  reification  ([M])  establish  a  correspondence  between  opaque 
and  transparent  representation  of  computations:  opaque  computations  may  only  be  con¬ 
structed  and  sequenced  using  1  and  let1,  while  transparent  ones  may  be  manipulated  using 
the  full  range  of  operations  available  on  the  type  Ta,  such  as  injections,  case  analysis, 
etc.  See  Example  2.26  below. 

Together  with  the  extension,  we  define  a  canonical  or  definitional  translation  of  the 
extended  signature  back  into  the  original  one. 

Since  we  will  be  dealing  with  several  source-to-source  translations,  let  us  introduce 
the  following  shorthand: 


Definition  2.22  (Translation  convention)  When  specifying  a  translation  [-]  from  a 
signature  L  to  L1  that  share  a  lot  of  operations,  we  generally  omit  clauses  of  the  form 

[^(A'1,...,.Y„)]  =  V([A'1] . [A'„]) 

where  the  construct  tp  in  L  is  translated  to  the  same-named  construct  in  L1 .  (We  do 
occasionally  include  selected  clauses  of  this  form  for  emphasis  or  clarity;  but  no  formal 
distinction  should  be  attached  to  whether  a  clause  is  included  or  not.) 

Definition  2.23  The  monadic  translation  [-]T  maps  types  and  terms  of  LT  to  their 
L- counterparts,  such  that: 

•  For  any  Ea  or  type  in  LT ,  Ea  [o]t  type  in  L. 

•  For  any  Ea  0  ctype  in  LT ,  Ea  [/5]t  ctype  in  L. 

•  For  any  T  Ea  M  :  a  in  LT ,  [T]t  Ea  [M]t  :  in  L. 

The  translation  on  types  merely  replaces  'a  with  its  definitional  expansion: 


['n]T  =  T[q:]t 


Other  type  constructor's  are  left  intact,  as  are  type  variables  (i.e.,  [a]T  =  a).  Similarly, 
the  term  translation  expands  away  the  new  term  constructors: 


['ML 

[let°  x  <=  Mi  in  M2  (:  'o)]T 
[let1  x  ■$=  M\  in  M2]T 

W«)l, 

lout 


VWlr 


letTHr  1  •*=  Mir  111  Mir 

(A:C.[iV2]T)*[A/,]r 

[M\t 

Mr 


with  variables  and  other  term  constructors  of  L  translated  into  themselves  (but  with  any 
type- annotations  expanded  according  to  the  type  translation). 
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Although  the  monadic  translation  is  simply  a  definitional  extension,  rather  than  a 
full  syntactic  transformation,  we  adopt  the  translation  formulation  to  get  an  explicit 
syntactic  handle  on  the  expansion.  In  particular,  when  we  later  consider  alternative 
ways  of  translating  away  the  new  constructs  of  LT ,  it  will  be  convenient  to  have  an 
concise  notation  for  referring  to  the  different  expansions. 

Note  also  that  because  type  and  term  variables  are  translated  into  themselves,  the 
translations  are  compositional  in  the  sense  that 

{a{a'/a }]T  =  [«]T{[a']T/a}  and  \M{M' /x}\T  =  {M\T{{M'\T /x}  . 

In  particular, 

{Ta]T  =  [Ta{a/a}]T  =  [Xa]T{[«]T/a}  =  Ta{[a]T/a}  =  T[a\T  , 

and  likewise  for  the  term  translations  of  the  monad  components:  [?]Q]T  =  r)[ajT  and 
[/*]T  =  /*  (with  the  implicit  type-tags  on  -*  appropriately  translated). 

The  translation  of  the  “mixed  let”  may  need  a  little  explanation.  Consider  the  case 
where  T  is  the  state  monad,  and  the  base  effect  is  partiality.  Then  if  in  the  extended 
language,  F  h  M\  :  °»i  (i.e. ,  evaluation  of  M\  may  diverge,  but  has  no  state  effects), 
[Mi]t  :  °[«i]T  does  not  take  a  state  argument,  nor  does  it  return  a  new  state.  On  the 
other  hand,  when  T,  x:  a  h  M2  :  'a 2  (i.e.,  M2  may  both  diverge  and  access  the  store), 
[M2]t  :  a  — >■  °( [o2JT  x  cr),  so  the  translation  of  M2  should  be  passed  the  current  state, 
and  the  new  state  it  returns  is  the  state  returned  by  the  whole  let-expression.  The 
appropriate  state-passing  translation  is  therefore 

[let°  x  ■$=  Mi  in  M2\T  =  As.  let  °  x  ■$=  [Mi]t  in  [M2]T  $ 

which  is  precisely  what  the  generalized  let  expands  to. 

More  generally,  it  is  easy  to  check  the  following  derived  rule,  where  3  is  an  LT - 
computation  type  (i.e.,  may  contain  '): 

[let^  x  4=  Mi  in  M2]T  =  let^T  x  ^  [Mi]t  in  [M2]T 

In  the  definitional  translation,  the  opaque  and  transparent  T-computations  are  rep¬ 
resented  by  the  same  underlying  L-type;  consequently,  the  term  translations  for  reflection 
and  reification  are  trivial.  Later,  when  we  consider  a  different  representation  of  effects, 
the  two  operators  will  have  more  interesting  definitions. 

This  syntactic  translation  also  determines  a  semantics: 

Definition  2.24  Given  a  semantics  C  for  our  base  language  L,  we  obtain  a  semantics 
CT  of  the  extended  language  LT  by  taking 

CT{af  =  C[[a]T]'  and  £T[M]'  =  C[[M\T]e 

In  fact,  this  semantics  extends  the  standard  monadic  semantics  for  the  new  ambient- 
effect  monad  induced  by  T: 
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Proposition  2.25  Let  £  be  a  predomain  semantics  of  L0  with  some  underlying  ambient- 
effect  monad,  T  a  uniform  monad  in  that  semantics  (Definition  2.19),  and  let  |-|  : 
Lq  — >■  Lq  be  the  syntactic  transformation  replacing  every  °  in  types  and  terms  with  '. 

Then  £T[|-|]  =  £r[_]  (for  types  and  terms)  where  C-j-  is  the  jnonadic  semantics  of 
L0  for  the  ambient- effect  monad  T  given  by  interpreting  in  £  the  components  of  T,  as 
shown  in  Proposition  2.20. 

Proof.  Induction  on  the  structure  of  the  types  and  terms.  Most  cases  are  immediate; 
for  computations,  we  get: 

£T[Hf  =  £Tf\a\f  =  £[['H]Tf  =  £lTl\a\Ue  =  £[(Ta){[|a|]T/a}f 

=  £[Ta]0tah^£HMM^  =  £[Ta]a^£HMM*  ik  £[Ta]a^£rW*  =  T{£tM°) 

=  W«]’ 

pwm’w  =  £Tm\t  w  =  =  c\nwy  iimi  tfw 

=  £[l(M]TrW(£[[|M|]TrW)  =  £K{[|«|]T/a}]*(p)(4[|M|]T]*W) 

a  £H“^"I*(.)(£t[M]»(p))  ={£tW,(£t[M]»w)  =  £t[-m]«(p) 

The  case  for  let°  x  <=  Mi  in  M2  is  similar.  ■ 

Similarly,  given  an  evaluation  semantics  for  £  (i.e. ,  a  computable  partial  function 
Evalc  from  closed  L-terms  of  type  °i  to  natural  numbers),  we  get  an  evaluation  semantics 
for  £T  by  taking  Evalcr(M )  =  Evalc{\M\T).  (We  can  do  this  directly,  regardless  of  T, 
because  the  T-translation  of  a  term  of  type  °i  is  itself  a  term  of  type  °i.) 

It  is  worth  remarking  that  when  T  is  the  “identity”  monad  (Ta  =  °a,  i]  =  Xx.°x, 
f*t  =  let°  a^t  in  fa),  the  translation  effectively  replaces  all  occurrences  of  1  in  the 
source  term  with  °: 

[M\t  =  (A:W:r)[A/]T  =  °{M}t  =  {°M\t 

[let1  x  X=  Mi  in  M2]T  =  {Xx.  {M2\T)*  [M^  =  let°  a  <=  [Mi]t  in  {Xx.  {M2\T)a 
=  let°  x  <$=  [Mi]t  in  [M2]T  =  [let°  x  <=  M\  in  M2\T 

so  when  we  later  exhibit  a  relation  between  the  T-translation  and  a  monadic  translation 
for  a  continuation  monad,  we  will  get  a  relation  between  direct  and  continuation-passing 
style  in  the  presence  of  arbitrary  (sufficiently  well-behaved)  ambient  effects  by  simply 
taking  T  to  be  the  identity  monad. 

Defining  T-specific  operators  The  reflection  and  reification  primitives  allow  us  to 
define  the  meanings  of  effectful  terms  as  abbreviations  within  the  extended  language, 
instead  of  through  additional  clauses  in  the  translation  equations. 

Example  2.26  When  T  is  the  exception  monad,  we  can  define  the  usual  ML-like  excep¬ 
tion  primitives 


F  b  M  :  'x  F  F  M\  :  'a  F,  x:  x  b  M2  ■  'cv 

F  F  raise  M  :  'a  T  F  try  M 1  handle  x  =X  M2  :  'a 
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as  follows: 


raise  M  —  let1  e.  y=  M  in  pt(°(  inr  e)) 
try  Mi  handle  x  =>  M2  —  let°  t  <=  in  case  (t,  a.'a,  X.M2) 

That  is,  to  raise  an  exception,  we  explicitly  construct  its  sum-representation  as  a  value 
in  the  right  inject,  then  “activate”  it  by  reflecting  it  into  the  process  of  computation. 
Conversely,  to  handle  a  potential  exception  in  a  computation  Mx,  we  first  reify  Mx  and 
then  inspect  it,  taking  the  appropriate  action  for  either  of  the  two  possibilities  (normal 
or  exceptional  value). 

And  in  fact,  expanding  the  definitions  using  the  monadic  translation  gives  the  expec¬ 
ted  results: 

[raise  M]T  =  [let1  e  <=  M  in  g(°(  inr  e))]T  =  (Ae.  [/i(°(  inr  e))]T)*  [M]T 
=  let"  t  [M]t  in  case  ( t ,  e.[°(  inr  e)]T,  e.°(  inr  e)) 

=  let"  t  •<=  [M]t  in  case  ( t ,  e.°(  inr  e),  e.°(  inr  e)) 

[try  Mi  handle  x  M2]T  =  •  •  •  =  [let°  t  <^=  [Mx]  in  case  (t,  a.'a,  x.M2)\T 
=  let°  t  •<=  [[Mi]]t  in  case  (£,  a.['a]T, x.M2) 

=  let"  t  -4=  [Mx]t  in  case  (t,  a.°(  ini  a),  x.\M2\T) 


2.3.2  Induced  equational  theory 

The  translation  induces  a  natural  equational  theory  on  terms  of  the  extended  language: 

Definition  2.27  Given  an  equational  theory  £  (including  the  ell  axioms)  for  L  and  a 
monad-triple  T  in  L,  the  equational  theory  £T  for  LT  consists  of  £  extended  with  the 
following  rules  (where  we  write  ®  for  °  and  ®  for  '): 

r  b  Mi  :  a\  T,  x:  011  b  M2  :  ^a2 

- (i^-  7  'l 

r  b  (let®  X  ^®Mi  in  M2)  =  M2{M1/x}  :  ®a2 
T  b  M  :  ®a 

T  b  (let®  x  <^=  M  in  ®rc)  =  M  : 

r  b  Mi  :  ®«i  r,  x\  \  oi\  b  M2  :  Sa2  T,  x2:  a2  b  M3  :  ^0:3 

- - - (i<j<k) 

r  b  (let0  x2  •<=  (let®  x\  •<=  M\  in  M2)  in  M3) 

=  (let®  x\  •<=  Mi  in  let0  x2  <^=  M2  in  M3)  :  ®«3 
r  b  M  :  M  T  b  M  :  Ta 

r  b  //,( [M] )  =  m  -.'a  TVu((m)Y^WTta 

r  b  Mi  :  Ml  r,  x:  a\  b  M2  :  M2 

T  b  [let°  x  •<=  Mi  in  M2]  =  (let^Qo  x  •<=  Mx  in  [M2])  :  Ta2 

r  b  M  :  cr  r  b  Mi  :  Mi  T,  x:  a\  b  M2  :  M2 

r  b  ['M]  =gM  :Ta  V  b  [let1  2;  4=  Mi  in  M2]  =  (AA  [M2])*  [Mx]  :  Ta2 

(The  instance  i  =  j  =  k  =  0  in  the  first  three  rules  is  already  part  of  £.) 
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Proposition  2.28  The  equational  theory  is  sound  for  the  monadic  translation,  in  the 
sense  that  if  Ad  =  M'  is  provable  in  £T ,  then  \M\T  =  [M']T  is  provable  in  £  extended 
with  the  monad  laws  for  T  (which  may  or  may  not  already  be  provable  in  £ ).  This  again 
implies  that  £[[M]T]  =  £[[M']T]  in  any  model  C  of  £  in  which  T  is  a  monad. 

Proof.  Simple  equational  reasoning,  using  Proposition  2.9  (the  derivable  equational 
properties  for  the  generalized  let).  For  example, 

[let°  x  <=  "Mi  in  M2  :  'a2jT  =  lety[ao]r  x  <=  °[Mi]r  in  [M2]T  =  lM2jT{[MijT/x} 

=  {M2{M1/x  }]t 

[let1  x  <=  'Mi  in  M2]t  =  (Xx.  [M2]T)*  (r,  {MijT)  =  (Xx.  [M2]T)  {MijT 

pef  x2  <=  (let°  x\  <=  Mi  in  M2)  in  M3  :  'a3]T 

=  letT[Q3]T  ^2  (let°  X!  <=  \Mi}t  in  [M2\T)  in  [M3]T 

=  let2>3]T  *1  «=  IMi1t  in  letT[03]T  X2  <=  lM2 ]t  in  1Ms}t 
=  [let°  X]  <=  Mi  in  let°  x2  X=  M2  in  M3]T 

[let'  x2  <=  (let°  x |  <=  Mi  in  M2)  in  M3]T 

=  (Arr2.  [M3]t )*  (lefrIaa]T  xx  ^  \Mi}t  in  [M2]T) 

=  letT[ct3]T  X1  <=  IMi]t  in  (A x2.{M3]t)*  [M2]t 
=  [let°  x |  Mi  in  let'  x2  X=  M2  in  M3]T 

[['M]]T  =  ['M]T=r,[M]T  =  [r/M]T 


The  first  three  rules  of  Definition  2.27  say  that  let-elimination  and  let-flattening  are 
valid  even  for  mixed  levels,  as  long  as  the  types  match.  That  is,  there  is  a  single  notion  of 
computation-sequencing  shared  by  all  effects;  the  level-tags  merely  keep  track  of  which 
kinds  of  effects  can  happen  where. 

The  next  two  express  that  reflection  and  reification  are  exact  inverses.  For  example, 
in  the  exception  case,  there  is  a  one-to-one  correspondence  between  “dynamic” ,  effectful 
computations  of  type  ‘a,  that  may  raise  exceptions,  and  “static”,  exception-free  values 
of  type  °{a  +  y). 

The  remaining  three  equations  show  that  [-]  acts  as  a  “shallow”  version  of  the  mon¬ 
adic  translation.  According  to  the  first  one,  terms  with  ambient  effects  only  are  unaffected 
by  reification  for  the  focus  effect,  and  may  hence  move  across  a  [-] -barrier  freely.  For 
example,  if  the  ambient  effect  is  state  and  focus  effect  is  exceptions,  a  computation  that 
cannot  raise  an  exception  can  be  moved  out  of  a  try-handle.  (The  equation  is  necessar¬ 
ily  satisfied  when  the  base  language  is  effect-free,  because  in  that  case  let°  is  simply  a 
substitution  of  AI\  for  x  in  M2.) 

The  final  two  rules  make  it  explicit  how  T-computations  are  realized  in  terms  of  the 
monad  operations,  enabling  us  to  reason  “locally”  about  propagation  of  effects  entirely 
at  the  extended-language  level. 

Moreover,  for  all  the  rules  it  is  the  case  that  when  the  LHS  is  type-correct,  then  so 
is  the  RHS.  Thus,  we  can  always  use  the  equations  from  left  to  right  without  worrying 
about  type  preservation. 

As  a  simple  consequence  of  the  proposition,  we  get: 
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Corollary  2.29  Let  |-|  :  L0  — >•  Lf)  be  the  translation  replacing  every  occurrence  of  °  in 

\T\ 

types  and  terms  by  '.  Let  C  be  a  model  of  £0.  Then  the  interpretation  C'Q  of  L0,  given 

IT1!  m 

-|]  is  also  a  model  of  So  (and  hence  in  particular  itself  a  co?nputational 
lambda-language) . 

Proof.  The  equations  for  numbers,  products,  sums,  functions,  and  fixed  points  follow 
immediately  from  the  translation.  For  computations,  take  i  =  j  =  k  =  1  in  the  first 
three  rules  of  £T  and  use  Proposition  2.28.  ■ 

Note  also  that  £T  implicitly  asserts  that  (T,  -*)  form  a  monad  in  LT ,  because  it  is 

easy  to  see  that  the  equalities 

rj  =  A  a.  ['a] 

/*  =  A t.  [let1  a  <=  n(t)  in  //(/a)] 

are  derivable,  and  the  monad  laws  for  r)  and  f*  then  follow  from  the  equations,  e.g., 

f*  (rj a)  =  (At.  [let1  a  <=  g{t)  in  g(f  a)] )  ['a]  =  [let1  a  •<=  /t(  ['a] )  in  g(f  a)] 

=  [let1  a  <=  'a  in  /i(/a)]  =  Lg{f  a)]  =  fa 

and  for  rigidity  of  /*: 

f*  (lety  x  <=  M  in  x)  =  [let1  a  4=  g{\et°Tai  x  <=  M  in  x)  in  //(/a)] 

=  [let1  a  <=  fi(let°T  x  <=  M  in  [//(re)] )  in  //(/a)] 

=  [let1  a  //( [let“  x  M  in  n(x)])  in  /i(/a)] 

=  [let1  a  <=  (let°  x  <=  M  in  p{x))  in  g(f  a)] 

=  [let°  x  <=  M  in  let'  a  <=  p{x)  in  g(f  a)] 

=  let^ao  x  <=  M  in  [let1  a  <=  g(x)  in  /i(/a)]  =  let^Q2  x  <=  M  in  f*x 

Example  2.30  We  can  use  the  extended-language  equations  to  verify  the  following  rj- 
like  rule  for  exceptions: 

(try  M  handle  x  raise  'x) 

=  let°  t  <=  [M]  in  case  (t,  a.' a,  a:. let'  e  <=  'x  in  /i(°(  i n r  e))) 

=  let"  t  <=  [M]  in  case  (t,  a.g{  ['a] ), inr  s))) 

=  let"  t  -<=  [M]  in  case  (t,  a.g(°(  ini  a)),x.g(°(  inr  a:)))  =  let"  t  -<=  [M]  in  g{°t) 

=  /i([let°  t  [M]  in  /i(°t)])  =  //,(let°  t  <=  [M]  in  [/i(°t)])  =  /t(let°  t  <=  [M]  in  °t) 

=  g  ( [M] )  =  M 

This  identity  is  crucial  for  pattern-matching  exception  handlers,  where  an  exception 
is  implicitly  re-raised  if  it  does  not  match  any  of  the  clauses  in  a  handler:  we  want  to 
ensure  that  such  a  handler  has  no  effect  on  the  result  of  the  program.  ■ 


2.4  Related  work 

There  has  already  been  much  work  on  combining  monadic  effects,  e.g.,  [Mog90,  KW93, 
CM93,  Ste94,  LH.J95,  Esp95],  of  varying  degrees  of  generality  and  formality.  None  of  these 
approaches,  however,  were  particularly  concerned  about  nonstandard  implementations  of 
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the  newly-specified  effects;  effectively,  they  all  interpret  programs  using  the  modular 
specification  directly,  often  at  a  significant  cost  in  execution  time. 

It  seems  likely  that  the  framework  outlined  here  for  the  two-level  case  generalizes  to 
multiple,  explicitly-specified  effects,  each  with  a  full  reflection  and  reification  operator. 
However,  the  primary  constraint  was  not  only  to  define  a  workable  notion  of  layered  effect, 
but  also  to  ensure  that  it  could  be  simulated  in  a  strong  sense  by  continuation-passing, 
and  further  by  escapes  and  state,  as  detailed  in  the  next  two  chapters.  Consequently, 
any  broader  modularity  aspects  of  the  approach  have  not  been  properly  developed. 


Chapter  3 

Relating  Effects 


It  is  part  of  continuation  folklore  that  continuations  provide  a  very  general  notion  of 
effects,  in  that  many  others  (such  as  partiality,  exceptions,  or  state)  can  be  expressed  as 
a  continuation  semantics  with  a  suitable  answer  type.  In  the  presence  of  higher-order 
functions,  however,  proving  correctness  of  a  continuation-based  simulation  is  decidedly 
non-trivial  [Rey74a,  Sto81,  MW85],  even  for  a  “purely  functional”  language  with  parti¬ 
ality  as  the  only  notion  of  computational  effect. 

In  this  chapter,  we  will  consider  the  relationship  between  a  direct  and  a  continuation 
semantics  for  arbitrary  monadic  effects.  In  fact,  the  continuation  semantics  can  itself 
be  conveniently  cast  in  the  monadic  mold,  making  the  result  a  particular  instance  of 
simulating  one  monadic  effect  with  another.  However,  the  continuation-passing  case  is 
especially  complicated,  and  a  significant  part  of  the  proof  consists  of  establishing  the 
general  framework  and  necessary  lemmas  for  this  case. 

Very  broadly,  the  general  idea  is  as  follows:  assume  we  have  two  monads  T  and  U 
over  a  base  language,  where  U  is  in  a  suitable  sense  “more  general”  than  T.  We  can 
then  give  two  different  translations  from  LT  to  L :  the  original  monadic  translation  for  T 
and  a  variant  translation  using  [/-representations  of  T-effects.  Moreover,  we  can  exhibit 
a  type-indexed  family  of  relations  <jQ  with  the  property  that  the  two  translations  of  an 
LT-term  of  type  a  are  related  by  <jQ,  and  such  that  the  relation  at  base  types  is  the 
identity.  Thus,  the  two  translations  induce  the  same  evaluation  semantics. 

3.1  Simulating  monadic  effects 

In  this  section,  we  present  a  general  principle  for  relating  effects,  introduce  the  vari¬ 
ant  translation,  and  argue  informally  for  its  correctness.  The  actual  simulation  proof, 
however,  will  be  postponed  until  Section  3.3. 

3.1.1  Monad  morphisms 

A  natural  way  of  relating  two  monads  consists  of  exhibiting  a  function  mapping  one  to 
the  other: 
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Definition  3.1  Let  T  =  (T,  r),-*)  and  U  =  (U,e,-+)  be  monads  over  a  ell  (L,C).  A 
(definable)  monad  morphism  from  T  to  U  is  a  type-indexed  family  of  L -ter ms, 


b {a}  'a  :  T a  — >■  U a , 


respecting  the  monad  structure,  i.e.,  such  that  the  following  holds  in  C  for  all  closed 
L -types: 

0.  b  \a  :  Ta  Af  JJa. 

1.  V-  iQ  o  rjQ  =  ea  :  a  ->■  Ua. 

2.  f  :  ai  ->■  Ta2  b  i«2  o  /*  =  (ia2  o  /)+  o  iai  :  To:,  ->■  Ua2 ■ 

We  can  think  of  i  as  converting  T-representations  of  effects  to  [/-representations.  Con¬ 
dition  (0)  is  a  technical  constraint,  ensuring  essentially  that  the  conversion  of  focus  effects 
respects  any  underlying  ambient  effects  (for  example,  a  nonterminating  T-computation 
must  be  represented  by  a  nonterminating  [/-computation).  More  explicitly,  (1)  says  that 
a  trivial  T-computation  is  mapped  into  a  trivial  [/-computation.  Condition  (2)  may  look 
somewhat  arbitrary  at  first,  but  note  that  it  can  be  written  in  the  form  of  a  conditional 
equality  emphasizing  the  parallel  to  (1): 

C2  °  /  =  9  =>  Co  °  /*  =  g+  o  iQ1 

(where  /  :  ay  — >■  Ta2  and  g  :  ay  — >■  Ua2).  It  expresses  the  requirement  that  if  g  is  the  U- 
counterpart  of  an  cti-parameterized  T-computation  /,  then  T-extending  /  and  converting 
its  output  is  equivalent  to  applying  the  [/-extended  g  to  the  conversion  of  the  input. 

Example  3.2  For  any  monad  U,  the  function  family 

ha  :  °a  — >■  Ua  =  Xta.let°Ua  a  <=  t  in  ea 

is  a  monad  morphism  from  the  identity  monad  I  (Example  2.16)  to  U: 

h  (let°  x  <=  m  in  x)  =  let^a  a  4=  (let”  x  <=  m  in  x)  in  ea 
=  letf/a  in  let  [fa  a  x  in  £a  =  let)/Q  x  <=  m  in  hx 

h  {go)  =  h(°a)  =  \et°Ua  as=°a  in  ea  =  ea 

h(f*t)  =  h  (let”  a\  <=  t  in  f  a\ )  =  let”  «2  <=  (let”  a\  <=  t  in  /  a\ )  in  e  ai 
=  let”  a\  <=  t  in  let”  a2  <=  f  a\  in  ea2  =  let”  a\  <=  t  in  h  (/ a\) 

=  let”  a\  <=  t  in  (h  o  f)+  (ea\)  =  (h  o  /)+  (let”  a\  <=  t  in  ea\)  =  ( h  o  /)+  (h  t) 

In  fact,  it  is  the  only  such  morphism.  This  is  immediate  when  the  base  language  is 
effect-free  (condition  (1)  with  7]  =  id),  but  it  also  holds  in  general:  Suppose  h'  :  °a^Ua 
is  another  monad  morphism  from  I  to  U.  Then 

h '  t  =  h7  (let”  x  <=  t  in  °x)  =  let'):h  x  <=  t  in  h7  (°x)  =  let^Q  x  <=  t  in  h7  (yx) 

=  let^Q  x<=t  in  ex=ht 
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This  captures  the  intuitive  notion  that  any  effect  can  simulate  the  absence  of  effects, 
which  we  would  probably  consider  a  minimal  requirement  for  any  notion  of  effect  simu¬ 
lation.  ■ 


A  more  interesting  example  is  provided  by  the  following: 

Example  3.3  For  simplicity,  assume  that  our  base  language  includes  a  term  constructor 
+  :  z  x  /  — >  z,  satisfying  equations  0  +  M  =  M  +  0  =  M  and  Mi  +  (M2  +  M3)  = 
(Mi  +  M2)  +  M3  in  the  model,  i.e. ,  such  that  (/,  0,  +  )  forms  a  monoid.  (We  could  of 
course  have  defined  an  addition  operator  in  the  existing  language  using  recursion,  but 
that  would  necessarily  give  it  the  type  (XM  °z,  cluttering  up  the  terms  with  explicit 
sequencing  of  the  additions.  Still,  it  is  easy  to  check  that  everything  does  work  out 
correctly  even  for  a  defined  +.) 

Then  the  following  determines  a  monad,  usually  called  the  complexity  monad: 

Ta  =  °(a  x  z) 
rj  =  A  a.  °(a,  0) 

/*  =  At.  let °  (cii ,  n.i)  4=  t  in  let°  (a2,  n2)  4=  /ai  in  °(a2,  n i  +  n2) 

Here,  a  computation  of  type  a  is  represented  by  a  base-computation  yielding  a  value 
of  type  a  together  with  some  notion  of  the  cost  involved  in  computing  it,  such  as  the 
number  of  floating-point  operations  performed  (perhaps  using  an  encoding  of  floating¬ 
point  numbers  in  terms  of  /  ),  or  the  amount  of  I/O  (assuming  our  ambient  effects  include 
some  notion  of  communication  with  the  outside  world).  A  trivial  computation,  ija, 
resulting  from  viewing  an  already  given  value  as  a  computation,  has  zero  cost:  the  cost 
of  evaluating  f*t  is  the  sum  of  the  cost  n \  of  computing  the  value  cq  of  t  and  the  cost 
n2  of  evaluating  /  at  a  \ . 

The  complexity  monad  works  by  summing  the  complexities  of  each  subcomputation. 
But  if  most  subcomputations  do  not  invoke  the  operation  being  counted,  this  is  poten¬ 
tially  wasteful,  since  we  will  be  adding  zeros  most  of  the  time.  Even  more  important, 
complexity  is  a  fairly  “ad  hoc”  monad,  so  that  we  will  most  likely  have  to  perform  an 
actual  translation  to  get  a  language  with  the  corresponding  monadic  effects. 

There  is  an  alternative  way  to  keep  track  of  complexity,  however:  maintain  a  running 
total,  which  is  updated  only  by  the  cost-incurring  operations  themselves,  and  passively 
transmitted  everywhere  else.  We  achieve  this  using  the  /.-state  monad  (Example  2.18): 

Ua  =  z  — >■  °(a  x  /),  £  =  Aa.  As.°(a,  s),  f+  =  Xu.Xs.let°  (a,  s')  <^=  us  in  fas' 

We  can  then  represent  a  computation  of  a  with  complexity  n  as  a  function  adding  n  to 
the  current  total,  in  addition  to  returning  a.  And  in  fact, 

\a  =  XtTa .  AsMet°  (a,  n)  -<=  t  in  °(a,  s  +  n) 


is  a  monad  morphism  from  T  to  U. 


48 


CHAPTER  3.  RELATING  EFFECTS 


We  now  formally  define  a  very  important  class  of  monads: 

Definition  3.4  Let  o  be  any  computation-type.  Then  the  continuation  monad  with  an¬ 
swer  type  o,  K0  =  ( K0,e,+  )  is  given  by: 

K0a  =  (a  — >■  o)  — >■  o,  e  =  Xa.  Xk.  ha,  f+  =  Xu.  Xk.u(Xa.  f  ah) 

It  is  easy  to  check  that  this  actually  determines  a  monad.  For  rigidity  of  /+,  we  have: 

f+  (let^Q  x  <=  m  in  x)  =  Xk.  (let^Q  x  <=  m  in  x)  (Xa.  fak) 

=  A  A:,  let"  x  <=  m  in  x(X  a.  fak)  =  A  A.  let"  x  <=  m  in  f+  xk 
=  letj‘.n  x  <=  m  in  f+x 

Satisfaction  of  the  other  three  equations  is  completely  straightforward. 

The  importance  of  continuation  monads  stems  from  the  following  property: 

Lemma  3.5  Let  T  =  (T,r),-*)  be  a  monad  in  a  computational  X-language,  and  let  7 
be  an  arbitrary  type  (not  necessarily  computational).  Take  U  as  Kjy,  the  continuation 
monad  with  answer  type  T 7.  Then  the  family  of  functions 

\a  :  Ta  — >■  Ua  =  A tTa .  AA:“^T‘I .  k*  t 

forms  a  inonad  morphism  from  T  to  U. 

Proof.  Straightforward  verification: 

i  (letyQ  t  <=  m  in  t)  =  A k.k*  (letyQ  t  4=  m  in  t)  Xk.let°Tl  t  rn  in  k*t 
=  Xk.letf^  t  <=m  in  \  tk  =  let^  t  <=m  in  it 

i  (go)  =  A  k.k*  (go)  A  k.k  a  =  ea 

i  (/*  t)  =  A  k.k*  ( f*t )  =t  Xk.  (Xa.k*  (fa))*  t  =  Xk.\t(Xa.  k*  (fa))  =  Xk.\t(Xa.  i  (/  a)  k) 

=  Xk.it  (Xa.  [Aa.  i  (f  a)\ a k)  =  (Xa.i  (f  a))+  (it)  =  (1  o  f)+  (it) 

(where  the  equations  marked  with  t  signify  application  of  the  monad  laws  of  T  from 
Definition  2.15).  ■ 

When  T  is  the  identity  monad,  this  (necessarily)  degenerates  to  an  instance  of  Ex¬ 
ample  3.2.  More  interestingly, 

Example  3.6  For  exceptions,  Ta  =  °(a  +  \),  the  monad  morphism  from  T  to  K77 
specializes  to: 


\a  =  At4°+W  Xka^  t7+x3,  let"  v  ■$=  t  in  case  (a,  a.kca,  e.°(  inr  e)) 

Recall  that  the  T-representation  of  a  successful  computation  of  type  a  is  an  included 
value  a  in  the  left  inject  of  a  +  \.  The  corresponding  continuation-passing  computation 
should  immediately  apply  its  continuation  to  a.  And  in  fact,  we  have 

i  (°( ini  a))  =  Xk.  let"  v  <=  °( ini  a)  in  case  (v,  a.ka,  e.°(  inr  e)) 

=  Xk.  case  ( ini  a,  a.ka ,  e.°(  inr  e))  =  Xk.  ka 
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Similarly,  a  computation  that  terminates  with  a  raised  exception  e  is  represented  by  a 
value  in  the  right  inject;  the  continuation-passing  analog  simply  discards  the  current 
continuation  and  returns  the  exceptional  value  as  the  result: 

i  (°( inr  e))  =  Xk.  let”  v  <=  °( inr  e)  in  case  ( v ,  a.ka ,  e.°(  inr  e)) 

=  Xk.  case  ( inr  e,  a.ka,  e.°(  inr  e))  =  A  A:.  °( inr  e) 

And  finally,  a  nonterminating  computation  is  represented  by  a  non-terminating  compu¬ 
tation  (for  any  continuation): 

i  A  =  Xk.  let”  v  7=  i  in  case  (v.  a.ka,  e.°(  inr  e))  =  Xk.  A 


This  monad  morphism  from  an  arbitrary  monad  T  to  a  continuation  monad  Ky7 
will  form  the  core  of  our  simulation  result.  However,  the  fact  that  the  continuation- 
based  representation  is  in  a  sense  parametric  in  the  choice  of  7  cannot  be  captured 
equationally  in  our  setting.  (It  might  be  possible  in  a  language  with  ^-polymorphism 
[Gir72,  Rey74b].)  For  the  formal  proof  in  Section  3.3,  we  will  therefore  need  a  stronger, 
relational  characterization  of  i  to  accurately  express  this  property. 

3.1.2  The  variant  translation 

In  this  section,  we  show  how  to  actually  exploit  the  existence  of  a  monad  morphism 
(with  some  further  properties)  to  simulate  one  kind  of  effects  with  another.  Specifically, 
we  will  show  how  to  interpret  our  T-enriched  effect  language  in  terms  of  [/-effects.  The 
exposition  is  slightly  simplified  in  that  we  consider  only  a  single  semantics  for  the  base 
language  —  the  actual  proof  in  Section  3.3  distinguishes  between  a  specification  and  the 
implementation  semantics,  mostly  to  make  get  a  result  of  sufficient  strength  to  support 
Chapter  4.  However,  the  formal  definitions  we  give  are  general  enough  for  both  cases. 

As  motivated  in  the  previous  section,  monad  morphisms  give  us  a  simple  way  of  relat¬ 
ing  two  notions  of  effects.  Nevertheless,  a  monad  morphism  by  itself  does  not  guarantee 
that  [/-effects  simulate  T-effects  in  any  useful  sense.  For  example,  for  any  T  there  is  a 
(unique)  monad  morphism  from  T  to  the  degenerate  monad,  ( Ua  =  l,e  =  Xa.(),f+  = 
id  1 ) .  To  get  a  proper  simulation,  we  also  need  a  way  to  recover  the  T-representation  of 
an  effect  from  its  [/-representation: 

Definition  3.7  Let  i  be  a  monad  morphism  froin  T  to  U.  A  monad  retraction  at  type 
a  is  a  left  inverse  of  \a,  i.e.,  a  term  jQ  :  Ua  — >■ Ta  such  that  ]a  o  \a  =  id^a-  We  say  that 
such  a  retraction  is  schematic  if  all  the  ]a  are  themselves  members  of  a  term  family,  i.e., 
if  la  =  ja{«/a}. 

We  usually  expect  at  least  ]L  to  exist;  this  gives  us  a  way  of  extracting  meanings  of 
complete  programs.  In  many  cases,  however,  it  is  easy  to  find  a  suitable  inverse  at  all 
types: 

Example  3.8  For  the  complexity-state  simulation  from  Example  3.3,  where  in  particular 
the  monad  morphism  was  given  by 

iQ  =  Xt  :"XA  A.sAlet."  (a,  n)  -<=  /  in  °(a,  s  +  n) , 
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taking 

jQ  =  Xu'-(ny'!.uQ 

determines  a  monad  retraction  at  all  types.  That  is,  to  actually  extract  the  complexity 
of  a  computation  from  its  state-passing  representation,  we  simply  initialize  the  state  to 
zero,  perform  the  computation,  and  read  off  the  complexity  as  the  final  state. 

It  is  easy  to  see  that  this  j  is  a  schematic  left  inverse  of  i.  It  is  not,  however,  a  monad 
morphism  from  U  to  T:  it  does  not  in  any  meaningful  sense  simulate  arbitrary  state¬ 
passing  computations  using  complexity-effects.  ■ 


Given  terms  typed  like  the  monad  morphisms  and  retractions,  we  can  give  a  different 
translation  of  our  effect-enriched  language  LT ,  back  into  T,  using  a  U- based  represent¬ 
ation  of  T-effects  instead  of  the  T-representation  from  the  definitional  translation.  To 
define  the  translation  itself,  of  course,  we  do  not  need  to  assume  any  equational  properties 
of  the  terms  involved: 


Definition  3.9  In  L,  let  T  and  U  be  monad-triples,  and  let  i  be  a  family  of  terms  such 
that  for  any  LT -type  a,  i[Qj  :  — >■  [/[cv],.,.  Further,  let  K  be  a  set  (finite  or  infinite) 

of  LT -types  and  for  every  a  in  K,  a  term  j[Qj  :  — ?•  TfaJj,  . 

Now,  let  Lt^  be  LT  but  with  reification  restricted  to  K -types ,  i.e.,  with  [-]  :  t-Tck 

only  for  a  in  K.  We  then  define  the  variant  or  implementation  translation  from  LT ^  to 
L  as  follows.  For  types,  we  take 

K  =  u{< 

(so  for  the  type  translation  we  have  and  for  terms, 


I'm  i; 

[let1  x  <=  Mi  in  M2fT 
[let°  x  <=  Mi  in  M2  :  'affT 

mrt 


e\M  j’T 

(Ax.[  M2]'t)+IMi]'t 

letC/[a]'T  X  <=  Wl Ft  in  lM2 Ft 

!h't  M't 

Jh't  ImI't 


(We  write  fF(-)  and  [-]T  to  emphasize  that  these  are  reflection  and  reification  operators 
for  T,  not  U.)  Like  the  definitional  translation  (Definition  2.23),  [-J^  is  easily  seen  to 
preserve  types,  i.e.,  ifT  M  :  a  in  LT  then  [r]'T  [M]'T  :  in  L. 


Of  course,  when  U  =  T,  with  \a  =  jQ  =  id^a  (trivially  a  monad  morphism  with  a 
schematic  retraction),  we  get  exactly  the  original  [-]T -translation  as  a  special  case.  In 
general,  however,  we  now  have  [Ta]'T  =  T[o]'t  7^  G[a]'T  =  the  transparent  and 

opaque  representations  of  a  computation  with  T-effects  are  different.  This  is  why  for  re¬ 
flection  we  need  to  internalize  a  T-representation  of  an  effect  into  a  [/-representation  that 
fits  with  the  rest  of  the  [/-passing  translation.  Conversely,  for  reification,  we  externalize 
the  [/-representation  into  the  definitional  T-representation  of  the  effect. 

Although  the  definitional  and  the  variant  translation  of  a  type  are  in  general  differ¬ 
ent,  they  do  agree  on  base  types,  so  in  particular  the  results  of  transforming  complete 
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programs  (closed  terms  of  type  °t)  are  directly  comparable.  And  in  fact,  will  show  in  Pro¬ 
position  3.29  that  the  two  translations  of  a  closed  L^-term  of  type  °l  are  indeed  equal  in 
our  partiality  semantics  (and  appropriately  related  for  other  notions  of  ambient  effects). 

In  the  monad-continuation  case  of  a  monad  morphism  (Lemma  3.5),  it  is  not  obvious 
how  to  define  ]a  in  general.  We  will  see  in  Section  3.3.4  how  to  achieve  this.  For 
the  purposes  of  this  section,  however,  let  us  simply  restrict  ourselves  to  performing  T- 
reification  at  a  single  L-type  7  (as  opposed  to  at  arbitrary  LT-typos,  as  the  standard 
X-translation  allows  us  to).  That  is,  we  take  K  =  {7}. 

If  we  then  let  U  be  the  continuation  monad  with  answer  type  T 7,  we  can  directly 
take  j7  :  C/7  — >■  T 7  =  A u.urjj,  which  gives  us 

j7  M  =  (A u.urjj)  (A k.k*t)  =  (Xk.  A:*C)?]7  =  r/*t  =  t 
i.e. ,  that  j7  is  a  monad  retraction  at  7. 

Example  3.10  Let  Ta  =  °(a  +  x)  be  the  exception  monad,  with  the  continuation-based 
representation  Ua  =  =  (a  — >■  “(7  +  %))  — >■  “(7  +  7)  from  Example  3.6.  In  this  case, 

the  translation  equations  specialize  to: 

['M]'T  =  Xk.k[Mj'T 

[let1  x  4=  Mi  in  M2j’T  =  A k.  [Mi]'r  (Xx.  [ M2j'Tk ) 

[let°  x  7=  Mi  in  M2  :  'a]'T  =  AA'.let",^.  x)  x  7=  {Mij'T  in  [M2]'TA: 

lnT(M)]'T  =  AA:.  let°  t  7=  {MfT  in  case  (C,  a.ka,  e.°(  inr  e)) 

[[ MY}’t  =  {M]'t  (Xa.  °( ini  a)) 

(where,  for  the  third  equation,  we  have  used  Definition  2.4  to  expand  out  the  generalized 
let  in  Definition  3.9).  The  continuation-passing  analogs  of  raise  and  handle,  as  given 
by  the  expansions  in  Example  2.26  then  work  out  to: 

[raise  MJ'T  =  [let1  e  7=  M  in  /iT(°(  inr  e))]rT  =  Xk.  [M]rT  (Ae.  [/iT(°(  inr  e))]rT  k) 

=  AA;.  [M]7t  (Ae.  let°  t  7=  [°( inr  e)J'T  in  case  (i,  a.ka,  e.°(  inr  e) ) ) 

=  Xk.  {MJ't  (Ae.  let°  t  7=  °( inr  e)  in  case  (t,  a.ka,  e,°(  inr  e))) 

=  Xk.  [M]|»  (Ae.  case  ( inr  e,  a.ka ,  e.°(  inr  e)))  =  Xk.  [M]7T  (Ae.°(  inr  e)) 

[try  Mi  handle  x  =7  M2J'T  =  [let°  t  7=  [Mi]T  in  case  (t,  a.'a,  x.M2)]'T 
=  AA-.let°  t  7=  [[Mi]t]'t  in  case(t,a.l'afT,x.lM2fT)k 
=  Xk.let°  t  7=  [Mi]y  (Aa.°(  ini  a))  in  case(t,a.(Xk.ka)k,x.[M2J'Tk) 

=  Xk.let°  t  7=  [Mi]7t  (Aa.°(  ini  a))  in  case{t,a.ka,x.\M2\'Tk) 

(where  handle  can  only  be  used  with  expressions  of  type  '7)-  This  again  should  match 
the  operational  intuition  that  to  raise  an  exception  determined  by  M,  we  simply  return 
name  directly  as  an  answer  (tagged  as  a  right  inject,  so  that  an  enclosing  handle  can  tell 
the  difference).  Conversely,  to  handle  a  potential  exception  in  Mi,  we  invoke  it  with  the 
left  injection  as  the  continuation.  If  Mi  returns  normally  i.e.,  by  returning  ini  a,  we  pass 
a  to  the  continuation  of  the  handle.  On  the  other  hand,  if  M)  raises  an  exception  e,  i.e., 
returns  inre,  we  instead  evaluate  M2  with  x  bound  to  e,  again  in  the  control  context  of 
the  handle.  ■ 
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Comparison  Suppose  the  restrictions  on  reification  were  not  an  issue,  for  example 
if  we  were  content  to  only  allow  uses  of  handle  at  a  single  base  type  (not  an  entirely 
unreasonable  restriction;  we  still  have  raise  at  all  types).  Then  given  the  fairly  simple 
correspondence  between  “direct”  and  “continuation-passing”  definitions  of  exceptions, 
one  might  reasonably  ask  why  we  formalize  the  T-translation  at  all  -  why  not  simply 
take  the  continuation-based  [-]'T  as  the  “official”  definition  of  exceptions?  Then  we  could 
view  exceptions  as  simply  syntactic  sugar  for  the  corresponding  continuation  effects. 

The  problem  is  that  the  CPS  translation  does  not  satisfy  the  desirable  equational 
reasoning  principles  that  pure  exception-passing  does.  For  example,  consider  again  the 
reasoning  principle 

(try  M  handle  x  =>•  raise  'x)  =  M 

We  saw  in  Example  2.30  that  the  T-translation  verifies  this  law;  indeed,  it  is  provable  in 
8$  .  But  with  the  continuation-based  semantics  we  get: 

[try  M  handle  x  =>•  raise  1  .x ] ^  =  [let°  t  7=  [M]  in  case  (t,  a.' a ,  inr  *)))]* 

=  AA:.let°  t  <=  [[M]]'T  in  case  (f,  a.['a]'T  A:,  x.{n(°(  inr  x))]'T  k) 

=  Xk.let°  t  7=  j  [M]'T  in  case  (t,  a.ka,  x.\ (°( inr  x))  k) 

=  Xk.  let°  t  <=  [M]'T  rj  in  case  (t,  a. k  a,  x. k*  (°( inr  x))) 

=  Xk.  let°  t  7=  [M]'t  (Aa.  °( ini  a))  in  case  (t,  a.ka,  x.°(  inr  x))  =?  [M]'T 

It  is  easy  to  check  that  this  does  in  fact  hold  when  [M]'T  is  of  the  form  Xk.  ka  for  some  a, 
corresponding  to  an  effect-free  computation  of  a.  Similarly,  the  equation  is  satisfied  when 
[M] |  =  AA:.°(inre)  for  some  e,  corresponding  to  a  computation  raising  the  exception  e. 
Even  when  [M]'T  =  AA:._L,  representing  a  non-terminating  computation,  the  terms  have 
equal  denotations.  But  there  is  no  simple  guarantee  that  [M]'T  is  in  fact  in  one  of  those 
forms,  especially  when  M  may  call  an  “unknown”  function. 

For  example,  consider  the  case  7  =  l.  Then  one  element  of  the  type  ['ctjy  =  ([a]^-  — >■ 
°{l  +  y))  — )■  °(i  +  y),  is  AA:. °( ini  42),  which  we  could  call  an  exotic  T-computation:  it 
represents  neither  a  normal  value,  nor  a  raised  exception,  nor  divergence.  And  in  fact,  if 
[Mo]'t  =  AA:.  °( ini  42),  our  desired  reasoning  principle  fails  because  we  get 

[try  M0  handle  x  =>  raise  1 ./:][,  =  Xk.  A: 42  ^  Xk.  °( ini  42)  =  [M0]7T 

The  presence  of  such  computations  means  that  we  cannot  derive  the  identity  directly  in 
the  [/-model  -  we  need  a  much  more  elaborate  argument,  involving  at  least  an  induction 
over  all  syntactic  terms  in  the  language,  and  further  complicated  by  the  presence  of 
higher-order  functions. 

An  analogous  situation  holds  for  the  complexity-state  simulation  from  Example  3.3.  It 
is  easy  to  see  that  if  the  ambient  effects  are  commutative,  then  so  are  the  '-effects  defined 
by  the  complexity  monad.  General  state  passing,  on  the  other  hand,  is  not  commutative, 
so  again  we  lose  a  useful  equational  property  by  specifying  complexity-effects  directly  in 
terms  of  state-passing. 

That  does  not  mean,  however,  that  using  [-]'T  inherently  presents  a  problem  for 
formal  reasoning.  Recall  that  we  will  show  independently  that  the  [-]T-translation  and 
the  [-Jy-translation  do  agree  on  complete  T^-programs.  Since  the  equations  induced  by 
the  T-translation  are  (by  definition)  valid  for  observational  equivalence  in  Lq,  and  the 
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evaluation  semantics  induced  by  the  two  translations  is  the  same,  we  can  thus  reason 
about  effects  in  terms  of  their  (relatively)  declarative  T-specification,  rather  than  their 
derived  [/-implementation. 

Remark  3.11  In  the  particular  case  of  exceptions,  we  could  actually  construct  an  ad- 
hoc  continuation  semantics  where  the  translation  of  a  term  M  :  a  takes  both  a  normal 
continuation  (of  type  [«]— )>o)  and  an  exceptional  one  (of  type  y— »o),  invoking  whichever 
is  appropriate.  Such  a  translation  does  verify  the  handle/re-raise  equation  above,  and  it 
does  not  have  a  problem  with  the  choice  of  answer  type. 

However,  such  a  scheme  requires  all  translation  equations  to  be  modified  to  pass  the 
extra  continuation  along,  so  we  cannot  use  a  standard  cps  transform  for  the  bulk  of  the 
language.  And  even  more  importantly,  this  two-continuations  trick  does  not  generalize, 
because  it  relies  on  the  isomorphism  ((o;  +  y)  —t  o)  — >•  o  =  ((a  — » o)  x  (y  — >■  o))  — >■  o,  which 
does  not  have  a  counterpart  for  other  monadic  effects.  ■ 

3.2  The  proof  setting 

This  section  establishes  the  general  framework  for  the  simulation  proof  in  the  next  section. 
Much  of  the  material  is  relatively  standard,  and  has  consequently  been  relegated  to  an 
appendix. 

3.2.1  The  implementation  language 

The  base  signature  L0,  and  the  derived  Lf  need  to  be  tightly  constrained  because  we 
will  rely  on  induction  over  L^-types  and  -terms  in  the  proof.  The  target  language  for 
the  variant  translation,  on  the  other  hand,  need  not  be  restricted  to  simple  types.  And 
in  fact,  to  obtain  the  simulation  result  for  continuations  in  full  generality,  we  will  need 
more  of  the  structure  of  our  predomain  model  to  be  denotable  in  the  implementation 
language.  Accordingly,  we  now  define  the  required  extensions  for  expressing  (1)  a  weak 
notion  of  infinitary  sums  and  (2)  recursively-defined  types. 

Embedding-types 

To  simulate  T-reification  using  continuations,  we  will  need  to  embed  several  different 
types  into  a  single  type  of  answers.  A  suitable  construct  for  expressing  this  is  given  by 
the  following: 

Definition  3.12  The  signature  Lq  extends  Lq  with  a  new  type  constructor  E: 

Vz  G  I.  bA  ^(z)  type 
bA  EjK(z)  type 

where  (K(z))jg/  is  any  countable  family  of  -types  (possibly  with  repetitions);  we  usually 
abbreviate  E.,;K(z)  as  EK.  The  associated  term  constructor's  are: 


V  M  :  N(z) 

T  h  in,  .1/  :  EK(*e/) 


and 


Tl-  M  :  EH 

T  h  outd ,  .1  /  :  N(i)  +  l(?e/) 
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for  injecting  into  and  projecting  from  the  embedding-type.  Correspondingly,  £ff  extends 
£0  with  the  equations 

r  b  M  :  tt(z) 

T  h  outd,;  (in,; M)  =  ini  M  :  K(z)  +  l*'  e  ^ 

and 

TPM:  tt(z) 

F  P  outd,/  (in,M)  =  inr  ()  :  K( if )  +  l*'  ’  ^ 

From  outd,; ,  ice  can  define  a  derived  term  constructor, 

r  h  M  :  SH 

r  h  out,;  M  :  °^(z)(ie/) 

by  out,;  A/  =  case  (outd,  M,  a.°a,  T/ien  we  easily  get  the  following  derived  infer¬ 

ence  rule  in  £ff : 

TPM:  tt(z) 

F  h  out,;  (in,; M)  =  °M  :  °K(i)[l&I)' 

In  this  chapter,  in,;  and  out,;  with  the  above  equation  will  suffice  (in  particular,  we 
will  not  use  that  out,/  (in,;  A/)  =  _L  when  i  ^  *'),  but  in  Chapter  4,  an  explicit  outd,;,  not 
tied  to  any  particular  notion  of  ambient  effects,  will  be  more  convenient. 

It  is  important  that  even  for  infinite  index  sets,  embedding  types  do  not  introduce 
any  circularity:  each  summand  N(z)  must  already  be  a  well-defined  type  before  we  can 
form  EK. 


When  the  index  set  is  finite,  {zo ,  > . . ,  in  i  }•  we  can  simply  take 

EK  =  K(z0)  +  (---  +  (K(zn_i)  +  l)-) 

(the  terminating  1  merely  ensures  a  uniform  encoding  for  all  summands)  with  the  cor¬ 
responding  operations: 

in ioM  =  ini  M  outd ,0  M  =  case  (M,  a0.  ini  a,  s.  inr  ()) 

in ik+1M  =  inr  ( in,.  ,\I )  outd ik+1M  =  case  (M,  a.  inr  (),  s.outdiA.  s) 

which  are  easily  seen  to  satisfy  the  required  equations. 

In  the  general  case,  we  obtain  a  model  by  a  straightforward  extension  of  the  predomain 
semantics  to  /-indexed  coproducts: 


£[S,X(i)]»  =  {(i,a)  |ie/,ae£[N(i)]"} 

£[in, Mf(p)  =  [iXIMfip)) 


£[outd,Mf(p)  = 


when  C\M\°(p) 
when  £[A/]°(p) 


(i,a) 

(/,  a7),  i'  i 


It  is  immediate  to  check  that  this  interpretation  validates  the  equations. 
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Recursive  type  specifications 

Independently  of  the  embedding-types,  to  express  the  continuation-based  variant  trans¬ 
lation  of  reification  at  types  containing  we  will  need  a  recursively-defined  answer  type. 
Accordingly,  we  take: 

Definition  3.13  For  a  signature  L,  Ul  extends  L  with  a  new  type  constructor  pi  a.  a  with 
well-formedness  rule 

h{a}  a  type 
b 0  pa.  a  type  ’ 

and  new  term  constructors  rolla.Q  and  unroll aQ!  with  typings 

T  b  M  :  a{(p a.  a)/ a}  T  b  M  :  pa.  a 

-  and  - 

F  b  rolla  aM  :  pa.  a  T  b  unrolla.aAf  :  a{(pa.a)/a] 

Likewise ,  8 ^  extends  8  with  the  isomorphism  equations 

T  b  M  :  a{(pa.  a) /a]  F  b  M  :  pa.  a 

-  and  - 

T  b  u  n  roll  aQ,  ( rollaQ!  M)  =  M  :  a{(pa.a)/a]  T  b  roll  aQ,  (unrollaa  M)  =  M  :  pa. a 

(For  simplicity  we  do  not  allow  parameterized  recursive  types,  although  it  would  probably 
do  no  harm  to  include  them.) 

Unlike  the  case  for  domains,  not  every  predomain  equation  expressed  in  terms  of  the 
standard  cpo  constructors  has  a  solution.  (For  example,  consider  the  equation  V  =  V— >0, 
where  0  is  the  empty  set  organized  as  a  cpo;  both  assuming  V  empty  and  non-empty 
lead  to  a  contradiction.)  But  equations  arising  from  interpretations  of  -types  (which 
notably  require  codomains  of  arrow  types  to  be  computational,  thus  ruling  out  the  above 
counterexample)  do  have  solutions,  essentially  because  we  can  extend  the  interpretation 
of  a  parameterized  type  to  a  functor  in  a  suitable  category.  We  will  need  the  following 
result: 

Theorem  3.14  Let  b{a}  a  be  a  parameterized  type  of  Lf .  Then  there  exists  a  cpo  A 
with  an  isomorphism  i  :  A*  A. 

Proof.  See  Corollary  A. 8  in  the  appendix  (ignoring  for  now  the  additional  minimal- 
invariant  property  of  i ) .  ■ 


Then  with  the  interpretation  of  pa.  a  as  the  A  in  the  theorem,  rolla  a  as  i,  and  unrolla  a 
as  i~\  our  predomain  semantics  (for  any  T)  becomes  a  model  of  8^^. 

3.2.2  Admissible  relations 

Much  as  an  equational  theory  allows  us  to  reason  about  equivalence  of  terms  axiomatic- 
ally,  rather  than  about  equality  of  their  denotations  in  a  specific  interpretation,  we  can 
reason  about  more  general  relations  between  terms  at  the  syntactic  level.  That  is,  we 
first  establish  a  set  of  generic  relational  reasoning  principles,  validated  by  a  wide  range 
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of  interpretations.  If  we  then  confine  our  reasoning  about  programs  to  those  principles, 
the  results  will  necessarily  hold  in  each  particular  relational  interpretation. 

Our  denotational  semantics  associates  to  every  open  term  a  (continuous)  function 
from  the  meanings  assigned  to  the  free  variables  to  the  meaning  of  the  resulting  term. 
When  the  semantics  C  is  fixed,  we  use  the  term  constructors  of  L  directly  to  denote  this 
semantic  function.  For  example,  for  any  element  a  of  VaR  (a)  (not  necessarily  denotable 
by  a  closed  L-term),  we  write  ini  a  for  the  element  (1,  a)  of  VaR  (a  +  a'). 

Further,  when  o  =  [a\jx\y . . . ,  an/xn)  assigns  to  every  variable  xpati  in  T  a  value 
di  G  Val(cp)  =  £[cp],  we  write  M{a}  for  the  value  £[M](«[a:1 1— )•  ai, . . . ,  x1 1 — ^  O'!] ) .  (To 
improve  readability,  we  will  usually  write  M{a}  as  Ma;  the  two  notations  are  equival¬ 
ent.) 

Unlike  the  equational  case,  we  can  talk  about  relations  between  terms  of  two  different 
languages.  That  is,  given  (L,£)  and  (£,£)  we  say  that  R  is  a  relation  between  types 
a  of  L  and  a'  of  L'  if  it  is  a  relation  between  the  sets  VaR  (a)  and  Valued).  When  the 
languages  are  fixed,  we  write  simply  Rel(a,  a')  for  the  set  of  all  such  relations.  (Actually, 
we  will  only  be  interested  in  the  set  of  all  admissible  relations;  see  Definition  3.16  below. 
But  sometimes  it  is  useful  to  classify  a  relation  wrt.  types  before  we  have  established 
that  it  is  admissible.) 

The  motivation  for  considering  different  languages  is  that  when  implementing  a  mon¬ 
adic  effect,  we  may  need  different  resources  than  when  specifying  it.  In  particular,  U 
may  contain  constructs  not  in  L ,  with  C  providing  an  interpretation  for  those.  Moreover, 
C  and  £  may  arise  from  different  choices  of  the  base-effect  monad  T. 

This  means  that  we  can  specify  a  monad  T  over  ( L ,  £)  (say,  with  only  the  constructs 
of  Lq  and  with  partiality  as  the  only  ambient  effect),  and  show  how  to  implement  LT  using 
a  T'-translation  into  (I/,  £)  (say,  L0  extended  with  recursive  types,  and  a  continuation 
semantics  for  ambient  effects)  -  even  if  T  does  not  satisfy  the  monad  laws  in  £ . 

For  a  relation  R  G  Rel(a,  a'),  we  often  write  Ma  R  a'.P(a,a')  as  shorthand  for 
Ma  G  Val c(a),a'  G  VaR/  («').  a  R  a'  =>  P(a,a').  Similarly,  3a  R  a'.P(a,a')  abbreviates 
3a  G  VaR  (a),  a'  G  VaR/  (cd).  a  R  a'  A  P{a,  a'). 

We  can  now  isolate  the  subset  of  relations  we  will  be  working  with.  First,  we  define 
a  relational  analog  of  (pointed)  epos: 

Definition  3.15  A  binary  relation  R  between  (the  sets  underlying)  epos  A  and  A'  is 
called  chain-complete  if  for  any  pair  of  chains  ai  R  a2  R  •  •  •  in  A  and  a(  R  a/2  R  •  •  •  in 
A'  with  aj,  R  a'  for  each  i,  it  also  holds  that  (U?ai)  R  (U?ai)-  ^  relation  between  pointed 
epos  B  and  B'  is  called  pointed  if  Eb  R  Tb'  ■ 

We  can  then  define  a  suitable  notion  of  relations  for  our  predomain  semantics: 

Definition  3.16  Let  there  be  given  languages  ( L ,  C)  and  (L1 ,  £),  where  L  and  L'  are  ex¬ 
tensions  of  L0,  and  C  and  £  are  the  corresponding  extensions  of  the  predornain  se7nantics 
from  Section  2.1.3  (with  possibly  different  ambient- effect  monads). 

We  say  that  a  relation  between  types  a  of  L  and  a'  of  L'  is  admissible  if  it  is  interpreted 
as  a  chain- complete  relation  between  VaR(o)  and  VaR/ (o');  we  write  ARel(a,  a')  for  the 
set  of  such  relations.  Similarly,  a  computation-admissible  relation  between  types  j3  and 
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3'  is  one  whose  interpretation  is  chain- complete  and  pointed;  we  use  CARel(/3,  j3')  for 
the  corresponding  set. 

We  will  refer  to  such  a  pair  of  languages  with  type-indexed  sets  of  (computation-) 
admissible  relations  as  a  relational  correspondence.  (This  is  for  conciseness  only;  the 
correspondence  is  already  fully  determined  by  the  languages  themselves  and  the  above 
definitions  of  ARel(o,  o')  and  CARel(/5,  ft').) 

In  the  following,  we  enumerate  some  properties  of  (computation-)admissible  relations, 
especially  that  certain  stylized  methods  of  constructing  them  are  available.  The  proofs 
are  all  fairly  simple  and  can  be  found  in  the  Appendix. 

Given  these  properties,  we  can  reason  about  related  terms  entirely  within  the  base 
language,  without  referring  to  the  semantic  equations,  chains,  continuity,  etc.  explicitly. 
That  is,  although  we  will  not  consider  other  notions  of  (computation-)admissibility  than 
(pointed)  chain-completeness,  the  remainder  of  this  section  establishes  all  we  actually 
need  to  require  of  admissible  relations  for  establishing  the  results  in  Section  3.3. 

Lemma  3.17  Admissible  relations  are  closed  under  inverse  image  by  term  contexts  and 
under  arbitrary  intersection.  That  is, 

1.  When  R  £  ARel(o,  o'),  (aq:  Oi,  ...,xn:  an)  b  M  :  o  and  (x'1:a'1,...,x'n,:a'n,)  b 
M'  :  o'  are  terms  of  L  and  JJ  respectively,  and  for  all  i  >  2,  axi  £  Vafc(cp)  and 
o'x\  £  VaR/ (o'),  the  relation  R \  £  Re^o^o'R  given  by 

a,  R1  a)  <=*  .l/1"'/'1-0'  RM'A'JAT) 

is  admissible. 

Moreover,  when  aq  and  o\  are  cornputation-types,  R  is  computation- admissible, 
and  the  functions  \x\.Ma  and  A x'l.Mla  are  rigid,  then  R\  is  also  computation- 
admissible. 

2.  When  ( Rj)jeJ  is  an  arbitrary  (not  necessarily  finite  or  even  countable)  family  of 
admissible  relations  between  a  and  a',  the  relation  fl jej  Rj  i-s  admissible,  where 

a  (Hjej  -^j)  a'  ^ ')  ^  J.  a  Rj  a' 

Moreover,  if  each  Rj  is  computation- admissible  then  so  is  f| j^jRj- 

Proof.  See  Lemma  A. 9.  ■ 


We  also  have  a  simple  way  of  combining  existing  relations  on  individual  types  into 
relations  on  constructed  ones: 


Lemma  3.18  The  standard  relational  actions  of  the  type  constructors,  defined  by 


u  T  u 
p  (R1  x 1  R2)  p' 
s  (R1  +r  R2)  s' 

f(R i  -^r  R2)  S' 


3n  £  N.  i  =  n  A  i!  =  n 
true 

fst  p  Ri  fst  p  A  snd  p  R2  snd  p 

(3a!  Ri  a(.  s  =  ini  ai  A  s'  =  ini  a'fi) 

V  (3a2  R2  a'2.  s  =  inr  a2  A  s'  =  inr  a'2) 
Va  R]  a',  fa  R2  fa' 
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are  admissible.  Specifically,  when  all  the  R's  are  admissible,  so  are  T ,  l1',  Ri  x1'  R2, 
R.\  +r  R2,  and  R.\  —A  R2.  Moreover,  when  the  S ’s  are  computation- admissible,  so  are  lr, 
Si  x1'  S2,  and  R  —A  S. 

(We  often  omit  the  -r  when  it  is  clear  form  the  context  that  the  action  is  on  relations.) 
Note  that  the  relational  action  of  °  is  not  in  general  explicitly  definable  within  the  lan¬ 
guage;  we  characterize  it  in  Definition  3.20. 

Proof.  We  can  actually  show  admissibility  of  l1',  R1  x1'  R2  and  R1  —A  R2  using  only 
Lemma  3.17.  The  first  case  is  simply  an  empty  intersection  of  (computation-)admissible 
relations.  The  constructed  relation  for  products  is  the  intersection  of  the  two  admissible 
relations  obtained  by  inverse  images  of  the  projections  on  the  admissible  relations  R\  and 
R2.  Moreover,  since  projections  are  rigid,  Ri  x  R2  is  also  computation-admissible  if  both 
R.\  and  R2  are.  Finally,  R.]—>R.2  can  be  expressed  as  an  intersection  of  the  family  {R'-)j&Rl 
of  admissible  relations,  where  each  i?'-  is  given  by  an  inverse-image  construction:  f  R'{a 
f  -<=>  f  a  R2  fa'.  And  again,  since  application  is  rigid,  computation-admissibility  of 
R2  implies  computation-admissibility  of  R\  — >■  R2. 

The  cases  for  natural  numbers  and  sums,  on  the  other  hand,  depend  on  the  specifics 
of  the  model;  see  Lemma  A. 10(1, 2).  ■ 

The  reason  for  restricting  attention  to  (computation-)admissible  relations  is  that  they 
validate  the  following  binary  version  of  fixed-point  induction : 

Lemma  3.19  Let  S  €  CARel(/5,  (3'),  and  let  f  e  Val c{/3  — >■  / 3 )  and  f  e  VaR/  {[3'  — >■  (3') 
be  such  that  Wb  S  b'.fb  S  f'b'.  Then  fiX/3  f  S  fixjjr  f . 

Proof.  See  Lemma  A.  11.  ■ 

Effectively,  this  is  saying  that  for  any  computation-admissible  relation  S,  the  two 
interpretations  of  fix  are  related  by  (S  —A  S )  —A  S. 

3.2.3  Computation-extension  of  relations 

A  key  concept  we  will  make  use  of  in  the  following  is  the  extension  of  a  value-relation  to 
a  relation  on  computations.  Intuitively,  two  computations  are  considered  related  if  they 
both  have  the  same  (or,  more  generally,  related)  effects,  and  if  any  results  they  pass  on 
to  further  computations  are  related  by  the  original  relation. 

For  example,  in  the  case  of  partiality,  two  computations  are  related  if  they  either 
both  diverge,  or  both  converge  to  related  values.  For  exceptions,  two  computations  are 
related  if  they  produce  related  successful  answers,  or  raise  the  same  exception.  For  state 
(given  a  fixed  relation  on  states),  they  must  map  related  initial  states  to  related  values 
and  related  final  states.  And  for  two  control-computations  to  be  related,  when  invoked 
with  related  continuations  (i.e. ,  mapping  related  values  to  related  final  answers),  they 
must  themselves  produce  related  final  answers. 

Much  as  monads  abstract  out  the  common  equational  properties  of  effects  into  a 
simple  set  of  axioms  for  the  unit  and  extension  functions,  we  can  characterize  the  minimal 
requirements  for  a  relation-extension  as  follows: 
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Definition  3.20  A  computation-extension  of  relations  assigns  to  any  pair  of  types  a 
and  a',  and  admissible  relation  R  €  ARel(et,  a'),  a  computation- admissible  relation  °R  G 
CARel(°0',  V),  such  that  for  all  admissible  R,  R\  and  R2,  the  following  holds: 

1.  Ma  R  a1.  °a  (°R)  V. 

2.  If  Va  Ri  a',  fa  (°R2)  fa' 

then  Mm  (°R\)  m' .  let°  x  <=  m  in  f  x  (°i?2)  let”  x'  <=  m!  in  f'x'. 

That  is,  if  two  terms  are  related  as  values,  their  inclusions  into  computations  must  also 
be  related.  And  if  two  parameterized  computations  are  related  for  every  pair  of  related 
parameters,  they  must  remain  related  when  prefixed  by  related  computations  computing 
values  for  those  parameters.  A  simple  instance  is  given  by  the  following: 

Proposition  3.21  In  the  standard  partiality  semantics  (i.e.,  with  TA  =  T'A  =  A±f), 
taking  for  any  R,  °R  to  be  the  lifting  of  R,  i.e., 

m  ( °R )  m  <G=>  (3v  R  v'.m  =  °v  A  m  =  V)  V  (■ m  =  _L-a  Am'  =  T-ai ) 

determines  a  computation- extension. 

Proof.  Lemma  A. 10(4)  shows  that  °R  is  computation-admissible.  Condition  (1) 
(v  R  v'  =>  °v  (°R)  V)  is  also  immediate.  For  (2),  assume  m  (°R\)  ml  and  Va  R1 
a',  fa  (°i?2)  fa'-  There  are  two  cases,  one  for  each  disjunct  in  the  definition  of  “iR: 

•  m  =  °v  and  m'  =  °v'  for  some  v  R\  v'.  Then  we  get  the  result  directly  by  assumption 
on  /  and  f: 


let°  x  <=  m  in  / x  =  / v  (°i?2)  f'v'  =  let”  x'  <=  m'  in  f'x' 

•  m  =  T,  m'  =  _L.  Then,  by  the  second  disjunct  in  the  definition  of  °i?2, 
let"  x  <=  m  in  / x  =  _L  (°i?2)  A  =  let°  x'  <=  m'  in  f'x' 
(using  Proposition  2.13  to  obtain  the  equalities) 


We  will  see  later  (Proposition  3.40)  how  to  systematically  construct  computation- 
extensions  for  effects  defined  by  an  explicit  monadic  translation. 

3.3  The  simulation  proof 

To  avoid  repetition  in  the  following,  we  first  define: 

Definition  3.22  (Persistent  assumption)  Throughout  this  section,  we  will  assume 
that  there  is  given  a  relational  correspondence  between  interpretations  Cs  of  Lq  (the  spe¬ 
cification  language )  and  f  of  a  signature  Lf  D  L0  (the  implementation  language^,  with 
a  fixed  computation- extension  of  relations.  In  particular,  all  unqualified  occurrences  of 
ARel(a,  a'),  CARel(/5,  /3'),  and  R  will  refer  to  this  correspondence. 
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For  concreteness,  it  may  help  to  think  of  Lf  as  L0  extended  with  recursive  types 
and  embedding  types  (which  is  what  we  will  use  in  the  monad-continuation  case  in 
Section  3.3.4),  Cs  as  the  partiality  semantics  and  £;  as  a  continuation  semantics  (for 
base  computations,  not  to  be  confused  with  a  continuation  monad  defined  in  (£(]",£;); 
we  will  use  such  a  continuation-based  interpretation  of  ambient  effects  in  Chapter  4). 


3.3.1  Overview 

A  monad  morphism  i  gives  us  a  simple  way  of  converting  a  T-computation  t  to  the 
[/-computation  representing  it,  by  taking  u  =  i at.  However,  this  simple  relationship 
does  not  extend  directly  to  functions  on  computations.  For  example,  given  a  function 
/  :  Ta  -^Ta' ,  how  would  we  obtain  the  g  :  U a  — >■  Ua',  representing  /? 

If  i  has  a  left  inverse  j,  we  could  try  taking  g  =  ia/  o  /  o  ja.  This  is  not  really 
satisfactory,  however:  for  example,  when  a  =  a'  and  /  is  the  identify  function,  we  get 
g  :  Ua  — >■  Ua  =  \a  o  jQ,  meaning  that  the  identity  on  Ua  would  in  general  not  be  the 
correct  representation  of  the  identity  on  Ta. 

A  better  approach,  therefore,  is  to  characterize  instead  what  a  correct  U- based  repres¬ 
entation  g  of  f  would  be,  for  example  by  requiring  it  to  satisfy  the  equation  \a'  °f  =  S'0  la¬ 
in  general,  then,  instead  of  a  function  from  higher-order  values  involving  T-computations 
to  the  corresponding  ones  with  [/-computations,  we  get  a  (binary)  relation. 

The  general  outline  of  the  proof  is  then  as  follows.  First,  for  any  type  family  a  in  Lq, 
we  define  a  family  of  logical  relations  ((a)),  and  show  that  for  any  relational  interpretation 
of  the  type  parameters,  the  two  interpretations  of  a  term  family  M  of  L0  are  related  by 
((a)).  In  particular,  this  means  that  the  term  components  of  any  monad-triple  T  in  L0  are 
related  in  the  two  interpretations.  This  gives  us  a  way  of  talking  about  related  T-effects 
in  the  two  languages,  even  when  T  is  not  a  monad  in  £;. 

We  then  define  the  general  notion  of  a  monad  relation  between  a  monad  T  in  the 
specification  language  and  a  monad  U  in  the  implementation  language.  This  is  a  more 
general  notion  than  existence  of  a  monad  morphism  from  T  to  U:  instead  of  assigning 
to  every  a  a  function  from  Ta  to  Ua,  we  only  assign  a  binary  relation.  More  precisely, 
to  every  relation  R  G  ARel(a,  a'),  we  assign  a  relation  ‘R  G  ARel (To:,  Ua'). 

However,  if  U  is  also  a  monad  in  the  specification  language,  any  monad  morphism  i 
from  T  to  U  induces  in  a  canonical  way  a  monad  relation  between  T  and  U,  by  taking 
t  (’ R )  v  <G=>  \t  {UR)  u,  where  UR  is  the  standard,  syntactically-derived  action  of  U  on 
relations.  This  way  of  constructing  monad  relations  covers  most  of  our  sample  monad 
simulations  -  all  except  the  general  monad-continuation  case. 

Given  a  monad  relation  between  T  and  U,  we  can  now  exhibit  a  family  of  relations 
indexed  by  L^-types  a,  <ja  G  ARel([a]T,  [a]p ),  defined  in  the  usual  inductive  way  for 
the  standard  type  constructors,  and  taking  <j.a=  '<ja  G  ARel(T[a]T,  [/[$§,-, ). 

Further,  we  show  that  the  two  translations,  [-]T  :  Lf  — >■  L0  and  [-]'T  :  Lf  — >■  Lf  of  an 
L^-term  of  type  a  are  related  by  Since  in  particular  <-t=  °(//),  this  says  that  the 
two  translations  coincide  for  complete  programs. 
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Returning  to  the  monad-continuation  case,  we  show  how  to  construct  the  appropriate 
monad  relation  between  T  and  K0  explicitly.  (Intuitively,  we  need  the  generalization  from 
an  equational  to  a  relational  characterization  of  the  relationship  between  the  monads  for 
the  same  reason  that  forced  us  to  adapt  a  relational  approach  for  higher-order  values: 
when  we  embed  non-simple  types  in  the  answer  type  o  of  the  continuation  monad,  the 
A'0-based  representation  of  T-effects  will  in  general  not  be  unique.) 

For  this  simulation,  we  also  rely  on  the  fact  that  our  implementation  language  may 
contain  additional  types  and  terms  beyond  those  in  Lq ;  in  particular,  depending  on  how 
general  a  notion  of  T-reification  we  want  to  simulate,  we  will  need  recursive  types  and/or 
embedding-types  to  construct  K0.  Once  we  have  established  the  monad  relation,  it  is 
a  simple  consequence  of  the  properties  of  <j  that  the  definitional  T-translation  and  the 
variant,  or  continuation-passing,  translation  agree  on  complete  programs. 

Finally,  we  show  how  to  lift  the  simulation  result  from  a  relationship  between  transla¬ 
tions  to  a  relationship  between  source  terms.  Specifically,  the  basic  motivation  for  adding 
reflection  and  reification  to  our  source  language  was  precisely  to  permit  programs  to  be 
written  in  direct  style  instead  of  in  effect-passing  style.  And  in  fact,  it  is  possible  to 
express  the  simulation  result  at  the  source  level,  by  defining  the  reflection  and  reifica¬ 
tion  operators  for  T  in  terms  of  those  for  K0.  Thus,  we  do  not  need  a  monad-specific 
variant  translation  for  implementing  T-effects  with  continuations,  but  can  use  a  fixed 
continuation-passing  translation  for  all  such  effects. 

3.3.2  Relating  standard  terms 

We  first  show  that  a  large  collection  of  terms  are  related  by  the  relations  determined 
systematically  from  their  types: 

Definition  3.23  Let  A  be  a  finite  set  of  type  variables,  6  a  substitution  of  closed  L0- 
types  for  variables  in  A,  and  6'  of  closed  Lf  -types.  Further,  let  g  assign  to  each  type 
variable  a  G  A  a  relation  g  a  G  ARel(0  a,  9'  a).  To  every  type  a  over  A  in  Lq,  we  then 
assign  a  relation  ((a))e  £  ARel(o'{0},  a{9'})  (such  that  {{fi))e£  CARel(/5{0},  (3{0'f))  as 
follows: 

«a  r  =  Qa 

w  =  ‘r 

«i»c  =  ir 

((«r  x  a2y  =  ((aiy  xr  ««2r 

«ai  +  a2»*  =  «ai))c +r  «a2»‘ 

W 

«  «»‘  =  W 

We  extend  this  definition  pointwise  to  relate  value-substitutions  o  and  o' ,  i.e.,  if  for  each 
(xpoii)  £  F,  (a Xi)  ((o-i))0  (cr'xi),  we  write  a  ((T))e  a1. 

The  (computation-)admissibility  of  these  relation  follows  directly  from  Lemma  3.18.  It 
is  also  easy  to  see  that  we  have  the  usual  weakening  and  substitution  principles, 

(( a))e  =  {{a))e[a^R]  (a  £  FTV(a))  and  {{a{cf /sfi))0  =  {{a))e[a^ia'r] 
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Lemma  3.24  (logical  relations  lemma)  Let  9  and  9'  be  substitutions  of  closed  types 
for  A-variables,  and  g  a  relation  assignment  for  9  and  9'  (as  in  Definition  3.23).  Further, 
let  T  and  a  be  a  type  assignment  and  a  type  over  A,  both  in  Lq,  and  let  M  be  a  term  of 
Lq  with  T  Ha  M  :  a.  Finally,  let  a  and  a'  be  substitutions  of  values  from  £s  and  £•  for 
variables  in  T,  such  that  a  ((T))e  a'.  Then  M0a  ((a))e  M°'a' . 

Proof.  By  induction  on  the  structure  of  M : 

•  Case  Xj,  where  o, )  G  F.  To  show:  x 9(7  (( afi)e  xfa',  i.e. ,  that  axi  ((oj))5  cCtj, 
which  follows  directly  from  the  assumption  on  a  and  o' . 

•  Case  z.  To  show: 

3n  e  N.  z9a  =  n  A  z9'a'  =  n 
Since  z0a  =  z,  we  can  simply  take  n  =  0. 

•  Case  s  M.  To  show: 


3 n  E  N.  s  ( Mda )  =  n  A  s  {Me'a')  =  n 
By  IH  on  M,  we  already  have 

3 m  G  N.  M0a  =  m  A  Me'a'  =  m 

so  we  get  the  result  by  taking  n  =  rn  +  1. 

•  Case  ifz  (M,  Mz,  x.  Mfi.  To  show: 

ifz  (. Mea ,  A&,  x.  Mesa)  (( a))e  ifz  (Me'a' ,  M9'17' ,  x.  M9'a' ) 

By  IH  on  M,  we  know  that  (in  £s)  M0a  =  n  and  (in  £;)  M0'a'  =  n  for  some  natural 
number  n.  There  are  then  two  cases: 

—  Case  n  =  0.  By  IH  on  M~,  we  get 

ifz  (z,  M9(f,x.s.  M9u)  =  A&  {{a))e  M =  ifz (z ,  M9)*' ,xs.  M9'*' ) 

—  Case  n  =  m  +  1.  Then 

ifz  (s  m,  M9a,x.  M9a)  =  M9a{m/x }  = 

and  analogously  on  the  RHS,  so  the  result  follows  by  IH  on  Ms,  in  the  type 
assignment  (r,x:/)  and  the  extended  substitutions  (a,  m/x)  and  {(j',rn/x). 

•  Case  ().  To  show: 

<r  ((ir  o°'a' 

which  is  trivially  true  by  the  definition  of  ((1))^. 

•  Case  (Mi,  M2).  To  show: 

(Mi,  M2)0tT  ((«!  x  a2))e  iAh.M>)°'n' 


That  is, 
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fst  {(Mi,  M2)0a)  ((oli))6  fst  ((Mi,  M2)*v) 

A  snd  ((Mi,  M2)0a)  ((a2))e  snd  ((Mi,  M2)0'a') 

Since  we  have 

fst  ((Mi,  M2)0U)  =  fst  (M0n,  M0a)  =  M0(T 
and  analogously  on  the  RHS  and  for  snd,  we  get  the  result  by  IH  on  Mi  and  M2. 

•  Case  fst  M  (snd  M  is  analogous).  To  show: 

fst  (M0a)  ({ai))e  fst  (. M0'a ') 

which  we  get  from  IH  on  M  and  the  first  conjunct  of  the  definition  of  ((ay  x  a2))e. 

•  Case  ini  M  (in r  M  is  analogous).  To  show: 

ini  M0a  ((ay  +  a2))e  ini  Me'a' 

By  the  first  disjunct  in  the  definition  of  ((rv,  +  a2))C  it  suffices  to  show  that 

M0a  {(a^)6  M0'a' 


which  we  get  from  IH  on  M. 

•  Case  case  (M,  xi.Mi,  x2.M2).  To  show: 

case  (. M0a ,  x2.M0a)  ((a))0  case  (M0,(T* ,  xi.M?' a' ,  x2.M%a' ) 

By  IH  on  M,  we  have  M0a  ((a i  +  a2))e  M°'a' .  Without  loss  of  generality,  assume 
that  we  are  in  the  first  case  of  the  definition  of  ((ay  +  a2))C  That  is,  M0a  =  ini  ai 
and  M°  a  =  ini  a\  for  some  a\  ((a-i))e  a\ .  Then 

case  (M0a ,  x1.A/fcr,  x2.M2 a)  =  case  ( ini  ai,  xi.Mfa,  x2.M0a)  =  M0tT{ai/xi} 

=  n  ;! 

and  analogously  on  the  RHS,  so  we  get  the  result  by  IH  on  Mi  using  the  extended 
substitutions  cy  =  (a,ai/xi)  and  a[  =  (a1,  a(/xi). 

•  Case  A xa.M.  To  show: 


(A xa.M)0a  ((a  -A  (3))e  (A xa.M)0,<T' 


I.e.,  that 

A xa{e}.M0a  ((a  >  p))e  \xa{e'\M0'a' 

Accordingly,  let  a  ((a))0  a';  we  must  show  that 

(Xxa{8} .  M0a)  a  ((P))e  (A xam.M0'a')a 

And  since 

(A  xa{0}.M0a)a  =  M0a{a/x}  =  M0(<J’(a/x)) 

we  get  the  result  by  IH  on  T,x:a  Ha  M  :  p  using  the  extended  substitutions 
<t i  =  (a,a/x)  and  a[  =  (<j',a'/x). 
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•  Case  M1M2.  To  show: 

This  follows  directly  from  IH  on  M\  and  M2,  and  the  definition  of  ((a  — (3))e . 

•  Case  °M.  To  show: 

°{M0a)  (( °a))e  \Me’a ’) 

By  IH  on  M,  M0a  ((a))g  M°'a' ,  so  the  result  follows  from  the  definition  of  ((°a))g 
and  the  properties  of  a  computation-extension  (Definition  3.20(1)). 

•  Case  let°  x  <=  AR  in  M2.  To  show: 


let"  x  <=  AI0a  in  M0a  (fa2))s  let°  x  <=  M?'a'  in  M|v 
By  IH  on  Ml5  we  have  Mfa  ((°oi))e  Alf'a' ,  i.e. , 

Alfa  (°((a i))e)  Mfv 

Similarly,  by  IH  on  AR  with  appropriately  extended  substitutions,  we  get 
Wat  ((ai))e  a[.  Me2^iaxix))  (°{{a2))Q)  M2(a'A</x)) 


And  from  those  two  facts  and  Definition  3.20(2),  we  get  the  required  result. 
•  Case  fix/j  M.  To  show: 

fix/3{0}  Mda  ((Sy  fi X/WMflV 
By  IH  on  M.  we  have  M0a  (((3  ->•  /3))e  M0V,  i.e., 

V6  (( py  b'.  M0ab  {{yy  m0'u'  r 


The  result  then  follows  directly  from  fixed-point  induction  (Lemma  3.19),  because 
((/ 3))e  is  computation-admissible. 


As  a  simple  corollary  of  Lemma  3.24,  we  obtain  that  the  two  interpretations  of  a 
monad-triple  are  related: 

Lemma  3.25  Let  T  be  a  monad-triple  in  L0.  Then  the  standard  relational  action  ofT, 
given  by 

t  ( TR )  t'  t  {{Ta))a^R  t' 

respects  the  monad  operations  in  the  sense  that  for  any  R,  R\,  and  R2,  the  following 
conditions  are  satisfied: 

0.  If  V  a  R1  a',  fa  ( TR2 )  fa' 

then  Mm  (°Ri)  m'.  let^ao  x  <=  m  in  f  x  ( TR2 )  let^,  x'  <=  rn'  in  f'x'. 
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1.  \/a  R  a'.r]aa  (TR)  i)a' a! . 

2.  IfVa  R1  a',  fa  { TR2 )  fa'  then  Vt  {TRf  t'.  ft  ( TR2 )  f'*t' 

Proof.  All  cases  are  simple: 

0.  By  assumption  on  /  and  f,  we  have 

/  ((a,!  ->•  Ta 2))ai^Bl^^  jf 

and  by  assumption  on  rn  and  m' , 

m  {{  ai))  m 

Then  use  Lemma  3.24  on  the  term 

xf  ai  — >■  Ta2,  xm:  °ai  h{ai;a2}  let^a2  x  <=  xm  in  xfx  :  T a2 

(which,  recall,  abbreviates  a  term  of  the  core  syntax,  given  by  expanding  the  gen¬ 
eralized  let  according  to  the  shape  of  T)  with  the  substitutions  a  =  (f  /xf,rn/xm) 
and  a'  =  (/' /x f,m' /xm). 

1.  Analogous  to  above,  using  the  term  xa:  a  h{a|  rj&xa  :  Ta. 

2.  Analogous  to  above,  with  xj:  ax  — >■  T a2,  xt:  T a,  hjai;a2|  :  T a2. 


3.3.3  Relating  computational  structure 

We  are  now  ready  to  characterize  what  it  means  for  two  monads  to  be  related: 

Definition  3.26  A  monad  relation  between  monads  T  =  (T,  r],  -*)  in  (T0,  Cs)  and  U  = 
(U,e,-+)  in  (£+,£;)  assigns  to  every  admissible  relation  R  G  ARel(a,  a')  a  computation- 
admissible  relation  'R  G  CARel (Ta,Uo/)  such  that  for  all  admissible  relations  R,  Ri, 
and  R2, 

0.  If  Vr/  Ri  a.  f  a  ('i?2)  9a' 

then  Vm  (°Ri)  m' .  let^a2  x  <=  m  in  f  x  ('R2)  let^.n,  R  -<=  m'  in  gx! . 

1.  \/a  R  a' .  r]aa  (’R)  £ai a' . 

2.  IfVa  Ri  a' .  fa  ('i?2)  9a'  then  Vt  {'Rf  u.  f*t  ('i?2)  5,+  u. 

Further,  we  say  that  an  Lf  -term  i ai  :  Ta1  — >■  C/cd  is  a  reflection  function  (with  respect  to 
the  monad  relation)  if  for  any  L0-type  a  and  relation  R  G  ARel(o:,  a1), 

3.  Vt  {TR)  t'.t{'R)  \  f 

Analogously,  a  reification  function  is  an  Lf -term  jQ/  :  Uol  — )>T«7  such  that  for  any  a  and 
R  G  ARel(a,  a1), 

4.  Vt  {'R)  u.t  {TR)  ]aru 
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(Note  that  since  T  need  not  satisfy  the  monad  laws  in  C\,  i  cannot  in  general  be  a  monad 
morphism.  Nor  do  we  explicitly  require  that  j„/  o  \n,  =  idjv,  although  it  often  does  hold.) 

An  important  special  case  is  when  a  monad-triple  T  =  U  is  a  monad  in  both  Cs 
and  C\.  Then  Lemma  3.25  shows  that  the  standard  relational  action  of  T  induces  a 
monad  relation  between  the  two  copies  of  T;  moreover,  for  any  a' ,  we  can  simply  take 
i ai  =  jQ/  =  id^a'-  (There  is  still  some  non-trivial  content  to  the  definition  in  this  case, 
because  Cs  and  could  be  different  models,  with  their  ambient  effects  related  only  by 
relation-extension. ) 

More  generally,  we  have  the  following  convenient  way  of  obtaining  monad  relations 
directly  from  monad  morphisms: 


Proposition  3.27  Let  T  and  U  be  monad-triples  in  L0  such  that  T  is  a  inonad  in  jCs 
and  U  is  a  monad  in  both  Cs  and  L\.  Further,  let  i  in  (L0,CS)  be  a  monad  morphism 
from  T  to  U.  Then  the  assignment  to  any  R  £  ARel  ( rv ,  a')  of  the  'R  £  CARel  (Tct,  Ua!) 
given  by 

t  ('R)  u  -<=>  i at  (UR)  u 

establishes  a  monad  relation  between  T  and  U. 

Moreover,  for  any  a1  of  Lf ,  i ai  is  a  reflection  function.  And  if  j  is  a  schematic 
retraction  of  i  in  ( L0,CS )  then  for  any  a'  in  Lf ,  j ai  is  a  reifi, cation  function. 

Proof.  First,  ‘R  is  computation-admissible,  because  it  is  defined  as  an  inverse  image  of 
the  computation-admissible  UR  by  the  rigid  functions  iQ  and  id^Q/.  Further,  we  have: 

0.  Let  m  (°R\)  m'  and  f  (R.\  — >•  'IT)  g  be  given.  To  show: 

iQ2  (let^QO  a  <=  m  in  fa)  ( UR2 )  let^^  a1  <=  m!  in  go! 

By  rigidity  of  iQ2  (Definition  3.1(0))  on  the  LHS,  this  amounts  to  showing 

let^ao  a  <=  m  in  iQ2  (fa)  (UR2)  let^  a1  <=  m1  in  go! 

We  get  that  from  assumption  on  rn  and  m ',  and  the  properties  of  U's  relational 
action  (Lemma  3.25(0)).  if  we  can  establish  that 

Va  Ri  a' .  iQ2  (fa)  (UR2)  gal 

And  that  was  precisely  the  assumption  on  /  and  g. 

1.  Let  a  R  a' .  To  show:  i  a(rjaa)  (UR)  ea>  a' .  By  Definition  3.1(1)  on  the  LHS,  this  is 
equivalent  to  showing 

sQ  a  (UR)  £ai  a 

which  we  get  from  Lemma  3.25(1)  for  U. 

2.  Let  t  ('Ri)  u  and  /  (R\  — >■  'R2)  g  be  given  as  in  the  hypothesis.  We  must  show  that 

i aAf't)  (UR2)g+n 
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Again,  using  the  property  of  a  monad  morphism  3.1(2)  on  the  LHS,  this  amounts 
to  showing 

(i«2  °  /)+('a iA)  (UR2)  g+u 

Now,  by  assumption  on  t  and  u,  we  have 

i ait  (URi)  u 


and  by  assumption  on  /  and  g, 

Va  Ri  a'.  (ia,  o  f)a  (UR2)  go! 
from  which  we  get  the  desired  result  by  3.25(2). 

3.  Let  t  ( TR )  t ']  we  must  show  that  t  (' R )  wt',  i.e. ,  that  i at  {UR)  i a>t'.  And  since  ia 
was  a  term  of  L0,  this  follows  from  Lemma  3.24  by  an  argument  analogous  to  those 
in  Lemma  3.25. 

4.  Let  t  {' R)  u;  to  show:  t  {TR)  j aiu.  From  the  assumption  on  t  and  u,  we  have 
i at  {UR)  u,  and  hence  again  by  Lemma  3.24  with  M  =  ja,  we  get  ]a  (i at)  {TR)  j ai  u. 
Then  cancelling  the  ja  and  \a  on  the  LHS  gives  us  the  result. 


A  monad  relation  with  reflection  and  reification  functions  is  exactly  what  we  need  to 
relate  the  definitional  and  the  variant  translation:  the  monad  relation  itself  relates  the 
computational  structure,  and  the  reflection  and  reification  functions,  where  they  exist, 
convert  between  effect  representations: 

Definition  3.28  Let  T  be  a  monad  in  (L0,  jCs)  and  U  a  rnonad  in  {Lq  ,  C\ ) .  with  a  monad 
relation  between  T  and  U.  Then  for  any  type  a  of  Lq  ,  the  relation 

<|Q  G  ARel([a];T,  [a]c, ) 

is  given  in  the  usual  way  by  induction  on  the  structure  of  a  (as  in  Definition  3.23,  but 
without  the  type  variables),  and  with  <jia=  froin  the  inonad  relation. 

Note  in  particular  that  since  the  standard  relational  action  of  T  in  Lemma  3.25  is 
also  given  by  Definition  3.23,  we  have  <tq=  T<a  for  any  L^-type  a.  We  can  now  state: 

Proposition  3.29  Let  there  be  given  a  monad  relation  between  T  and  U,  with  a  reflec¬ 
tion  function  i  at  every  type  [a][r  where  a  is  a  type  of  L^  .  Further,  let  K  be  a  family  of 
Lf -types,  with  j  a  reification  function  at  every  [K(z)]c, .  Let  T  h  M  :  a  be  a  term  of  Lq^ 
(i.e.,  with  reifications  only  at  types  in  H).  Then  for  any  pair  of  substitutions  of  < -related 
values  for  the  variables  in  F,  a  <r  c7,  we  have  \M\°r  <Q  [M]^f  (where  [-]'T  is  the  variant 
translation  from  Definition  3.9). 

Proof.  Given  the  definitions,  this  is  a  simple  induction  on  the  structure  of  M.  The  cases 
for  variables,  numbers,  products,  sums,  functions,  and  base  computations  are  exactly  as 
before  (Lemma  3.24).  For  the  remaining  constructs,  we  have: 
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•  Case  'M.  To  show: 

Follows  from  IH  on  M  and  Definition  3.26(1). 

•  Case  let°  x  <=  AR  in  M2  (of  type  'c^).  To  show: 

letTI«,lT  *  -*=  Wi]°  in  [MJJ  let;,|os|i:  x  -s=  [M,]?'  in  [A/2]f 

By  IH  on  AR  and  AR,  and  3.26(0). 

•  Case  let1  x  <=  AR  in  AR.  To  show: 

(A.c.[A/2]")*[A/,]"  <■* 

Follows  from  IH  on  AR  and  AR  using  3.26(2). 

•  Case  /j(A1).  To  show: 

[ME  <■«  iMf 

Since  <Ta  =  T<a ,  this  follows  from  IH  on  M  and  Definition  3.26(3). 

•  Case  [M],  To  show: 

WrT  <Tai[M]T 

As  above,  <Ta  =  T<ai  so  we  get  the  result  by  IH  on  M  and  Definition  3.26(4). 

•  Case  fix.  As  before,  we  need  to  check  that  is  computation-admissible,  where  (3 
may  now  also  contain  the  type  'a.  And  in  that  case,  computation-admissibility  of 

is  ensured  by  the  requirement  of  a  monad  relation  (Definition  3.26). 


Using  the  monad  relation  induced  by  a  monad  morphism  (Proposition  3.27),  Pro¬ 
position  3.29  immediately  gives  us  correctness  of  a  number  of  effect-simulations.  For 
example,  the  complexity-state  monad  morphism  from  Example  3.3  validates  the  state- 
based  maintenance  of  complexities. 

For  our  monad-continuation  simulation  in  full  generality,  however,  we  have  to  work 
a  little  harder.  To  obtain  reification  at  arbitrary  types,  we  cannot  use  purely  equational 
properties  of  the  monad  morphism  and  the  standard  relational  action  of  U  alone  -  we 
need  to  construct  the  appropriate  monad  relation  explicitly. 

3.3.4  Relating  monads  to  continuation-passing 

Recall  from  Example  3.10  that  the  main  limitation  of  our  monad-morphism  formulation  of 
the  continuation-based  variant  translation  was  its  incomplete  treatment  of  T-reification. 
Specifically,  it  did  not  directly  allow  us  to  define  a  reification  operation  (1)  at  more  than 
one  type  and  (2)  at  types  containing  '.  We  will  now  see  how  to  overcome  these  problems 
by  using  a  more  elaborate  monad  relation. 

At  the  same  time,  we  will  take  care  of  an  independent  technical  complication  (3) 
with  simulating  a  monad  T  with  a  continuation  monad  K0.  Following  Lemma  3.5,  we 
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would  expect  to  take  the  answer  type  o  to  be  T 7  for  some  7.  However,  the  constraints 
imposed  by  our  eventual  application  in  Section  3.3.5  will  not  always  allow  us  to  do  this. 
Specifically,  we  will  need  the  answer  type  to  be  expressible  as  °u  for  some  u,  but  T7  is 
not  necessarily  of  this  form. 

Fortunately,  the  relational  approach  allows  us  considerable  latitude  in  picking  the 
actual  answer  type  o,  as  long  as  it  is  “larger”  than  the  T 7  that  we  originally  needed.  (Be¬ 
cause  the  answer  type  occurs  both  positively  and  negatively  in  the  continuation  monad, 
we  cannot  express  this  condition  purely  equationally.)  For  conciseness,  we  formulate  the 
requirement  in  general  terms: 

Definition  3.30  An  answer-embedding  of  Lq -computation-types  cq  into  02  consists  of 
a  pair  of  functions  7*  :  cq  — >■  cq  and  7*  :  cq  — >■  cq,  such  that  in  Clt  (1)  7*  is  rigid  and  (2) 

7*  o  7*  =  id01. 

(Taking  cq  =  o2  =  T7  and  7*  =  7*  =  ^77  certainly  satisfies  these  requirements, 
and  still  gives  us  a  result  strong  enough  to  solve  problems  (1)  and  (2)  mentioned  above. 
Thus,  on  a  first  reading,  it  may  be  helpful  to  simply  ignore  all  occurrences  of  7 *  and  7* 
throughout  this  section.  However,  for  the  purpose  of  the  next  section,  it  is  important 
that  the  we  only  rely  on  the  weaker  properties  guaranteed  by  Definition  3.30.) 

We  are  now  ready  to  state  a  central  result  about  relating  monads  and  continuations. 
The  essential  trick  is  that,  although  we  commit  to  a  fixed  answer  type  for  the  continuation 
monad,  we  are  still  free  to  consider  all  possible  relational  interpretations  of  that  type: 

Lemma  3.31  (continuation-simulation  of  monads)  Let  T  be  a  monad  in  (L0,CS). 
Further,  let  7  be  a  type  and  o  a  computation-type  of  Lf ,  with  an  answer- embedding  7*  : 
Tj^-Yo  and  7 *  :  o— yTj.  Then  the  mapping  of  R  £  ARel(cr,  a')  to  'R  £  CARel  (Tc*,  K„a ') 
given  by 

t  (' R)  u 

s — r*  Veto  typein,  O  £  ARel ( cto ,7 ) .  k  £  VaR  (ct  — Y  T ctg ') -  k1  £  VaR  ( cJ  — Y  o) . 

(Va  R  a’,  ka  {TO)  7*  (k‘  a'))  =7  k ft  {TO)  7*  {uk') 

is  a  monad  relation  between  T  and  K0.  Moreover, 

\ai  =  A tTa  .A ka'^°.(f)*  ((7*  o  k)*t)  and  j7  =  Au(1'“°H°. 7*  (^(7*  0  %)) 

form  a  reflection  function  for  all  a'  and  a  reification  function  for  7. 

(Intuitively,  the  outer  quantification  over  07  allows  us  to  overcome  limitation  (1)  from 
above;  if  we  only  needed  reification  at  a  single  Lq- type  a,  we  could  simply  fix  cto  =  [a]T. 
Further,  the  inner  quantification  over  O  takes  care  of  (2),  by  replacing  a  fixed  relation 
on  answer  types  (where  in  particular  7  may  be  recursive)  with  a  stronger  parametricity 
condition.  And  finally,  as  already  mentioned,  we  need  7*  and  7*  f°r  (3). 

It  is  instructive  to  compare  the  cases  of  the  following  proof  with  the  corresponding 
ones  in  Proposition  3.27.  Although  some  common  structure  could  clearly  be  abstracted 
out,  it  is  probably  easier  to  follow  how  the  continuations  are  being  passed  around  in  a 
concrete  formulation.) 
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Proof.  First,  we  check  that  'R  is  computation-admissible  when  R  is  admissible:  'R 
is  defined  as  an  intersection  over  inverse  images  of  the  computation-admissible  relations 
TO  by  the  rigid  functions  k*  and  if*  o  Xu.uk1.  For  the  specific  requirements,  we  have: 

0.  Assume  Va  Rx  a',  fa  ('R2)  90!  and  m  (°RX)  m'.  To  show: 

let0Q2  x^=m  in  fx  {'R2)  let^^o)^0  x’  <=  m’  in  gx' 

i.e. ,  that 

let0oo  x  <=  m  in  f  x  ('R2)  AAA  let*  x'  <=  ml  in  gx'  k' . 

Let  O ,  A: ,  and  k'  be  given,  with 

Va  R2  a'.ka  {TO)  if*  {k1  a’) . 

We  must  then  show  that 

k*  (letyQO  x  <=  m  in  f  x)  {TO)  A*  (let*  x'  y=  rn'  in  gx'  k') . 

Using  rigidity  of  k*  (Definition  2.15(0))  on  the  LHS  and  rigidity  of  if*  (Defini¬ 
tion  3.30(1))  on  the  RHS,  this  is  equivalent  to  showing 

let0Qo  x  <=  m  in  k*  {f  x)  {TO)  let07  x'  <=  rn'  in  if*  {gx’  k') . 

Now,  by  Lemma  3.25(0)  and  the  assumption  that  rn  {°R\)  m' ,  it  suffices  to  show 
that 

Va  Rxa'.k*{fa)  {TO)  if'{ga'k') 
and  that  follows  from  the  assumption  that  fa  {‘R2)  ga'. 

1.  Assume  a  R  a'.  Then  for  O ,  A:,  and  k'  as  above,  we  must  show  that 

k*  {go)  {TO)  if*  {e a' k') 

i.e.,  using  law  2.15(1)  and  the  definition  of  e,  that 

A: a  {TO)  f(k'o') 

which  was  precisely  the  assumption  on  A:  and  k! . 

2.  Assume  Va  Rx  a',  fa  {‘R2)  ga'  and  t  {‘Rx)  u. 

Let  O ,  k  and  k'  be  given  as  before;  to  show: 

k*{ft)  {TO)  if*  {g+  uk') 

using  monad  law  2.15(3)  on  the  LHS  and  expanding  the  RHS,  this  amounts  to 
showing 

( A.r.  k*  (/ x))*t  {TO)  if*  (u  {Xx.gxk')) 

This  follows  from  the  definition  of  t  {'R2)  u  if  we  can  show  that 
Va  Rx  a! .  (Ax.  k*  (/ x))a  {TO)  if*  ((Xx.gxk1)  a1) 

i.e.,  that 

Va  Rx  a',  k*  (fa)  (TO)  'if  (ga'k1) 

And  that  follows  from  the  assumption  that  fa  (‘R2)  ga'. 
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3.  Again,  let  O,  k,  and  k'  be  given  with  Va  R  a',  ka  {TO)  i/A  (k1  a'),  and  t  ( TR )  t';  we 
must  show  that 

k*t  {TO)  f  (^((f  ofc'ft')) 
i.e. ,  cancelling  the  ip*  and  <p*  (Definition  3.30(2)),  that 

k*t  {TO)  {ip*  ok'yt' . 

By  Lemma  3.25(2),  it  suffices  to  show  that 

Va  R  a' .  ka  {TO)  {ip*  o  k')a' . 

And  that  was  precisely  the  assumption  on  k  and  k! . 

4.  Let  R  G  ARel(a,  7)  be  given,  with  t  {'R)  u.  To  show: 

t  {TR)  v'(u{o*  c  n~  ) ) 

Here  we  finally  need  to  instantiate  the  O  in  the  definition  of  'R.  Take 

a0  =  a,  O  =  R,  k  =  rja,  k'  =  <p*  o  r/7  . 

Clearly  this  O  is  admissible,  because  R  was  assumed  to  be.  Further,  let  a  R  a'. 
Then,  because  ry  respects  the  relational  action  of  T  (Lemma  3.25(1)),  we  have: 

ka  =  rja  {TO)  rja!  =  ip*  {(p*  {i]a'))  =  ip*  {k' a') 

From  the  assumption  on  t  and  u,  and  monad  law  2.15(2),  we  therefore  obtain 

t  =  rj*t  =  k*t  {TO)  ip*  (■ uk ')  =  ip*  {u{<p*  o  rj)) 


as  required. 


Although  the  construction  only  gives  reification  at  7  directly,  by  choosing  7  appro¬ 
priately,  we  can  define  reification  functions  at  other  types: 

Lemma  3.32  Let  there  be  a  monad  relation  between  T  and  U,  and  let  j7  :  U 7  — >■  T 7  be 
a  reification  function  at  (Lf -type)  7.  Let  a'  be  any  type  of  Lf  with  term  constructors 
e  :  a'  -7  7  and  <)  :  7  >  °a'  such  that  (in  jC-J  a:  a'  h  <5  (fa)  =  °a.  Then  the  term 

j^,(e,  6)  :  Ua  -^-Ta  =  \ula' .  (AsAlet^,  a  <=  8  s  in  r]ai  a)*  (j7  ((Aa“7e7  {ea))+u)) 

is  a  reification  function  at  a1 . 

Proof.  Let  a  in  L0  and  R  G  ARel(o',o:/)  be  given,  with  t  {'R)  u\  we  must  show  that 
t  {TR)  (i e,5)u .  Accordingly,  define  R1  G  ARel(a,  7)  by 


a  R1  s  <7=>  °a  {°R)  S s  . 
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This  is  clearly  admissible,  being  given  as  an  inverse  image  of  the  admissible  °R.  Moreover, 
from  the  assumption  on  e  and  6,  and  the  properties  of  the  computation-extension  °R 
(Definition  3.20(1)),  we  immediately  get 

Va  R  a' .  a  i?7  ea' , 

which,  together  with  the  assumption  on  t  and  u  and  the  properties  of  the  monad  relation 
(Definition  3.26(1,2)),  gives  us 

t  =  (A a.r]a)*t  ('i?7)  (Xa'.e  (ea'))+  u  . 

From  this,  we  get  by  the  assumption  on  j7  that 

t  ( TR 7)  j7  ((Xa'.e  (ea'))+u) . 

And  finally,  using  all  three  parts  of  Lemma  3.25  and  the  definition  of  i?7 , 
t  =  (Aa.  letyQ  a  <=  °a  in  r]a)*t 

( TR )  (As.let^,  a'  7=  8 s  in  rja')*  (j7  ((Xa'.e  (ea'))u+ ))  =  'pa,(e,5)u 
as  required.  ■ 


For  the  j  from  Lemma  3.31  specifically,  this  works  out  to: 

(e,  5)  =  A uK°a' .  (As7.  \et°Ta,  a  <=  5 s  in  rja)*  (p*  (u  (A a“\  (<f)*  o  rf)  (ea)))) 


Consider  now  an  L^-program.  Because  our  type  system  is  monomorphic,  every  [-]- 
operator  in  that  program  can  be  uniquely  labeled  with  a  specific  type.  There  is  thus 
only  ever  a  finite  set  K  of  L^-types  a  such  that  [o:]'T  needs  to  be  embedded  in  the  7 
from  Lemma  3.32.  (Note  that  this  is  a  static  property  of  the  program,  with  the  set  of 
reification-types  bounded  linearly  by  the  program  size.  This  in  contrast  to,  say,  finite 
unrollings  of  fixed  points,  where  we  cannot  a  priori  determine  how  deeply  to  unroll.) 

Thus,  we  can  simulate  reification  with  a  finite  sum,  if  we  are  willing  to  construct 
the  relevant  type  7  =  S,;[fl:(z)]/T  for  each  program.  In  fact,  for  any  finite  K  covering  all 
reifications  in  an  L^-program,  we  get  the  same  overall  result  when  using  any  larger  K  for 
defining  7.  We  can  thus  formally  define  the  evaluation  semantics  of  programs  resulting 
from  the  variant  translation  to  be  the  unique  meaning  determined  by  any  “sufficiently 
large”  finite  collection  K. 

Or,  we  can  use  a  single,  infinite  embedding  type  that  works  for  all  programs.  In 
particular,  we  can  simply  take  /  to  be  the  countable  set  of  names  of  closed  T^-types, 
with  K^cd)  =  a.  Giving  such  an  enumeration  is  unproblematic:  the  set  of  L$- types 
does  not  itself  contain  any  embedding-tvpes.  Also,  the  tags  themselves  are  inherently 
unstructured;  in  particular,  for  a  monadic  translation,  we  have  [in>Q>M]T  =  in<Q>[M]T, 
not  iri‘[Q]  ’[M]t.  (In  the  actual  ML  implementation,  we  use  an  extensible  data  type  for 
EK,  with  tags  dynamically  generated  and  assigned  at  each  instance  of  reification.) 


3.3.  THE  SIMULATION  PROOF 
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Embedding-types  alone  do  not  suffice  to  express  a  continuation-based  simulation  of 
reification,  however:  there  is  an  independent  problem  with  reifying  at  Lq- types  containing 
the  type  constructor  Suppose  for  simplicity  that  we  only  needed  reification  at  a  single 
Z^-type  q:o,  and  moreover  that  we  could  choose  the  answer  type  of  the  continuation 
monad  freely.  Then  it  would  seem  natural  to  simply  take  7  =  [a0]y  and  o  =  T 7. 

But  since  the  continuation-passing  [-[^-translation  is  itself  defined  in  terms  of  the 
answer  type  o,  this  would  require  us  to  solve  the  recursive  type  equation  o  =  Tfaojy 
exactly ,  which  is  too  strong  a  requirement  in  general.  Instead,  we  still  take  7  =  [07]^, 
but  only  o  =  T7.  In  fact,  the  latter  need  not  even  be  a  full  isomorphism;  an  answer¬ 
embedding  suffices. 

(Alternatively,  we  could  have  broken  up  the  recursion  by  taking  o  =  T 7  and  7  =  [o^It- 
This  approach  gives  a  slightly  simpler  abstract  correspondence  between  monads  and 
continuation-passing,  but  does  not  allow  us  to  express  the  construction  in  the  next  section 
in  full  generality.) 

3.3.5  Factorizing  the  variant  translation 

Although  it  translates  from  LT  to  L,  the  [-[^-translation  using  [/-effects  is  actually 
much  more  like  the  standard  [/-monadic  translation  [-]Er  from  Lli  to  L,  sharing  the 
type  translation  and  most  of  the  term  translation  clauses  with  the  latter.  The  only  non- 
standard  clauses  are  for  reflection  and  reification  of  T-effects.  And  in  fact,  we  can  express 
the  [-[^-translation  entirely  in  terms  of  the  [-]EE -translation  by  expanding  T-reflection 
and  reification  into  //  -definable  terms. 

In  practice,  this  means  that  if  we  have  a  good  (efficient,  convenient,  etc.)  way  of 
implementing  evaluators  for  Cjj  (whether  using  the  definitional  translation  for  U  or  some 
other  technique,  as  long  as  it  gives  correct  results  for  complete  programs),  we  can  ob¬ 
tain  an  evaluator  for  Ct  by  simply  viewing  T-reflection  and  -reification  as  definitional 
extensions  of  Lu . 

When  i  and  j  are  definable  in  Lq  (and  hence  invariant  under  the  translations),  this 
is  immediate:  we  can  simply  take  /jT(M )  =  //'  (i  .1/ )  and  [M]T  =  j  [.!/]'  .  When  U  is  a 
continuation  monad  with  a  recursively-defined  answer  type,  however,  it  will  be  more  con¬ 
venient  to  work  with  a  formulation  of  [/-effects  that  integrates  the  recursion  isomorphisms 
in  the  continuation-passing  translation. 

First,  since  for  any  monad-triples  T  and  U,  the  sets  of  types  of  LT  and  Lu  are  actually 
the  same  (given  by  the  type  constructors  of  L  together  with  ’),  we  use  the  name  T*-type 
for  a  type  from  the  extended  signature,  independent  of  the  actual  monad  (which  only 
affects  the  types  of  //(-)  and  [-] ).  We  can  then  define  a  suitable  notion  of  “native”  effects 
for  an  //-continuation  monad: 

Definition  3.33  Let  L  be  a  ell  signature.  Then  for  any  closed  L*-type  to.  the  signature 
LA'“  extends  L  with  a  new  computation-type  constructor 1  a ,  the  associated  value-inclusion 
and  two  lets  (with  types  as  in  Definition  2.21),  and  the  following  two  term  constructors: 

rhM:(Q4  °u)  — ^  °(jJ  T  h  M  :  'a 

T  h  fjfi(M)  : 7 a  T  h  [.!/]  '  : 
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Note  that  this  strictly  generalizes  our  previous  definition  of  a  monad-extended  signature, 
because  in  the  case  where  lo  is  actually  a  type  of  L  (i.e. ,  does  not  contain  any  '),  the 
above  is  exactly  what  we  get  by  taking  the  monad  T  in  Definition  2.21  to  be  K-^. 

Unlike  the  case  for  a  standard  monad-extension  of  a  signature,  however,  we  will  not 
always  be  able  to  translate  LK'a  back  into  L,  because  the  corresponding  monad  now 
involves  a  recursive  type  definition.  But  when  the  target  syntax  includes  p- types,  we  can 
give  such  a  translation: 


Definition  3.34  The  translation  [-]A.  :  LK'W  — >■  IT  is  defined  as  follows:  first  take 

Co  =  pa.  [cj]k.  and  o  =  °lu 

(where  the  type  translation  |-]K.  expands  'a  into  ([»]K.  — »°a)— »°a  and  preserves  all  type 
constructor's  of  L).  We  abbreviate  the  associated  isomorphisms  as: 


<f> 


roll 


a-H 


L) 


and  fi  =  unrolla.N^a  :  lo  M  [kj]^ 


(where  we  write  p  :  a  M  a1  to  summarize  the  typing  rule  of  a  term  constructor  p  building 
a1 -terms  from  a-terms). 

Then  the  type  and  term  translation  is  the  standard  monadic  translation  for  the  monad 
K0,  except  with  the  clauses  for  reflection  and  reifi, cation  reading: 


{pK(M)]K  =  AA:.let°  r  <=  [M]A.  (Aa.let°  o  <=  ka  in  °(ipo))  in  °{<j>r) 
[[M]a]k  =  Xk.let°  o  <=  [M]a,  (Aa.  let°  r^ka  in  ffir))  in 


Note  that  when  the  isomorphisms  are  identities,  as  we  can  always  trivially  ensure  when 
uj  is  only  an  L-type,  this  reduces  to  the  original  definition  of  a  monadic  translation 
(Definition  2.23)  because  of  the  law  let°  x  <=  M  in  °x  =  M. 

The  usual  direct-style  reasoning  principles  for  reflection  and  reification  from  Defini¬ 
tion  2.27  still  hold  for  the  more  general  notion  of  monadic  translation.  Specifically: 


Lemma  3.35  In  addition  to  the  equations  for  let  and  inclusion  from  Definition  2.27, 
the  following  equations  are  sound  for  the  \-\K -translation  from  Definition  3.3 f: 


PAUIY) 

[/iA(M)]A 

[  'MY 

[let1  x  <  Mi  in  Mf\K 
[let°  x  <$=  Mi  in  Mfi\K 


M 

Xk.Mk  =  M 
Xk.kM 

Xk.  IMiY  (Xx.  [M2]a  k) 

A  A:,  let”  x  <  Mi  in  [M2]A  A: 


(where  k  does  not  occur  free  in  any  of  the  Ms). 


Proof.  Simple  calculation:  we  mainly  have  to  verify  that  the  isomorphisms  cancel  out. 
For  example,  for  the  third  equation: 
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[['M]a']a.  =  A&.let"  o  4=  (Xa.  let"  r^=ka  in  °(fr))  in  °(fio) 

=  \k.let°  o  4=  (Xk1.  kl  [M]A. )  (Xa.  let"  r  4=&a  in  °(fr ))  in  °(fio) 

=  Xk.let°  o  4=  (let°  r  <=  k{MjK  in  °(<fr))  in  °(fo) 

=  A&.let"  r  4=  k  [M]A,  in  let°  o  4=  °(4>r)  in  °(ipo)  =  Xk.  let°  r  4=  &  \M\K  in  °(ip  (fir)) 
=  A&.let"  r  4=  &[M]A,  in  °r  =  X k.k\M\K  =  \Xk.kM\K 

The  others  are  similar.  ■ 

Note  again  the  similarity  of  the  direct-style  equations  characterizing  [-]  to  those  of  an 
explicit  continuation-passing  translation.  The  operational  intuition  is  that  jiK(M)  passes 
to  M  a  functional  representation  of  the  current  evaluation  context,  i.e. ,  the  continuation 
waiting  for  the  result  of  pK(M).  Conversely,  [M]K  evaluates  M  with  a  given  continuation 
and  returns  the  answer.  For  example,  taking  lo  =  we  have 

[let1  x  4=  p,K(Xk.  let"  r  4=  k 3  in  kr)  in  '(sa:)]K  (A a.°a) 

=  [^iA(Afc.let°  r  4=  k3  in  kr)]K  ( Xx .  [' ( s ic)] A  (A a.°a)) 

=  (A/c.let"  r  <=  k3  in  kr)  (Xx.  (A a.°a)  (sx))  =  (A/c.let"  r  4=  k3  in  kr)  (Xx.°(sx)) 

=  let"  r  4=  (Xx.°(sx))3  in  (Xx.°(sx))r  =  let"  r  4=  °(s3)  in  (As.°(si;))r 
=  (Am.  "(so:))  4  =  "5 

That  is,  k  gets  bound  to  the  function  Xx.°(sx)  and  applied  twice  to  3. 

Remark  3.36  The  circularity  inherent  in  allowing  lo  to  be  an  L*-type  is  genuine:  even 
without  fix  in  the  language,  it  is  possible  to  write  non-terminating  programs  in  LK~ul. 
For  perhaps  the  simplest  example,  take  lo  =  T.  Then  reflection  and  reification  (as  shown 
above,  they  are  still  two-sided  inverses)  give  us  an  isomorphism 

a;  =  T  =  (1  — )►  °u;)  — )>  °u;  9*  °lo  -4  °u; 

And  indeed,  we  can  define  a  diverging  term  by  the  usual  double  self-application  made 
type-correct  by  the  isomorphisms: 

cl  :  lo  — y  °lo  =  Xxw .  Dr]  (X().°x) 

d!  :  lo  =  n(XkI^  let°  x  4=  k  ()  in  dx) 

Cl  :  °lo  =  del1 

■ 

It  turns  out  that  picking  a  fixed  shape  for  the  answer  type  (i.e.,  requiring  it  to  be  of 
the  form  °lo )  necessitates  a  slight  twist  when  simulating  monads  whose  type  constructors 
do  not  contain  an  outermost  °;  this  is  why  we  allowed  the  answer-embedding  in  Defini¬ 
tion  3.30  to  be  a  retraction,  rather  than  a  full  isomorphism.  First,  we  slightly  transform 
the  monad  to  be  simulated: 

Definition  3.37  Let  T  =  (T,rj,-*)  be  a  monad-triple.  We  then  define  a  new  monad- 
triple  T  =  (T,fj,  -*)  as  follows: 

fa  =  °(Ta) 
f)  =  X  a.°(pa) 

f*  =  Xm.  let°  t  4=  m  in  °((Xa.  let^QO  r  4=  fa  in  r)*  t) 
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For  example,  for  state  (Example  2.18),  this  gives 

Ta  =  0(ffO°(aX(7)) 
fj  =  Xa.  °(As.  °(a,  s)) 

f*  =  Am.  let"  t  <=m  in  °(As.let°  (a,  s')  <=ts  in  let°  r  7=  fa  in  r  s) 

Now  Ta  does  have  an  outermost  °.  On  the  other  hand,  T  is  not  in  general  a  monad , 
even  if  T  was.  In  particular,  for  law  2.15(1)  we  only  get 

f*  (fja)  =  let°  t  <=  °(rja)  in  °((Xa.  let^Qo  r  7=  fa  in  r)*t) 

=  °({\a.let°Ta2  r  X=  /  a  in  r)*  (rja))  =  °(let°Ta2  r  4=  fa  in  r)  =?  f  a 

T  is,  however,  a  monad  “up  to  extensionality” :  when  evaluated  and  applied  to  a 
value,  fa  and  f*  (fja)  do  behave  identically: 

let°  r  <=  f*  (rja)  in  rs  =  let°  r  <=  °(let^Qo  r  <=  fa  in  r)  in  r  s 
=  (lety  r  <=  fa  in  r)  s  =  let°  r  <=  fa  in  rs 

And  in  fact,  our  construction  will  ensure  that  functions  like  /  are  always  “fully  applied”, 
so  that  we  can  use  fj  and  -*  instead  of  rj  and 

We  can  now  define  reflection  and  reification  for  T  in  terms  of  the  corresponding 
operators  for  continuations  as  follows: 

Theorem  3.38  Let  T  be  a  monad  in  (Lq,Cs),  and  let  M  be  an  iff  -program  without 
top-level  focus  effects,  (i.e.,  •  h  M  :  °l).  Further,  let  K  be  a  family  of  types  containing 
at  least  all  Lf -types  for  which  M  contains  a  reification-operator.  Take  to  =  T(E^),  a 
well-formed  (Lf)* -type,  and  in  (Lf)K'v  define  the  term  constructors  fiF(-)  and  [-]T  by: 

if  (M  )  =  jiK(Xk.  k*  (°M)) 

[M]T  =  let^a  t  7=  (Ar.let°  a  7=  out|f  in  fja)*  ([M]K  (Aa.r)(irija)))  in  t  (N(»)=a) 

Now  take  Lf  =  (LfY,  with  a  model  of  (SfY  from  Section  3.2.1.  Then  replacing 
all  T -reflection  and  -reification  operators  in  M  with  the  definitions  above  (picking  i  for 
each  reification  arbitrarily,  subject  to  the  constraint) ,  yields  an  (Lf)K'v  -program  M1  such 
that  [M]t  (V)  {M']K. 

Proof.  Let  to  =  [T(EK)]A.  with  associated  isomorphisms  be  as  in  Definition  3.34,  and 
take  7  =  E,;[K(*)]A.;  then  (uj]k  =  [T(Ett)]A.  =  T{m]K  =  T(S[N]A.)  =  T7.  It  is  also 
easy  to  see  that  the  functions  defined  by 

</>*  :  T7  — )•  °D  =  \r.°((f>r) 

rp*  :  "to  >  7 '7  =  Am.  let^7  o  <=  m  in  rfo 

form  an  answer-embedding  in  the  sense  of  Definition  3.30. 

Now,  using  the  i  from  Lemma  3.31  directly,  we  get  (omitting  a  few  tedious  let- 
simplification  steps): 
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Imt(m)Jk  =  bA'(A k.k*  (¥))],  =  lnK(Xk.  °((Xa.  let)),  r^ka  in  r)*  M))jK 

=  Xk.let°  r  <=  [A k.  °((A a.  let"),  r  <=  k a  in  r)*  M)\K  (Aa.let°  o  <=  ka  in  °(ipo))  in  °((f>r) 
=  A&.let°  r  <=  "((Aa.lety  o  <=  ka  in  ipo)*  [M]A.)  in  °((f>r) 

=  Xk.°(cf)((Xa.let°T^  o  <=  ka  in  tfjo)*  [M]A.))  =  Xk.cp *  ((A a. ip*  (ka))*  [M]A.) 

=  'Ha  1M}k  =  lv(M)}  T 

Similarly,  using  j  from  3.31  as  extended  by  Lemma  3.32  (with  e  =  in*  and  <5  =  out,;, 
satisfying  the  retraction  condition  by  definition),  we  get: 

IIM1T]K  =  [letyQ  t  <=  (Ar.let°  a  <=  out,;r  in  fja)*  ([M]K  ( Aa.  77  ( in  *  a)) )  in  tJK 
=  letrHA  1  <=  Um^kIk  (Aa.°(j?(in,a)))  in  (Ar. leL)-.^.  a  <=  out {r  in  rjaft 
=  letT[a]K  0<HML  (Aa.  °(<f)  (?7  (in,  a))))  in  (Ar.letj,^  a  out,r  in  rja)*(ipo) 

=  (Ar. letyjQj^  a^=  out ,r  in  rja)*  (let°Tj  o  <=  [M]A.  (Xa.cj)*  (77  ( in* a)))  in  ipo) 

=  (Ar.lety|QjK  a  •<=  out,; r  in  r/a)*  (</>*  ({MjK  (Aa.  (<£'  o  rj)  (in*a)))) 

=  j{a]K  (in,-  outi)  [M]a.  =  [[M]]'T 

We  can  thus  apply  Proposition  3.29  (with  empty  a  and  a')  to  get  the  result.  ■ 

Remark  3.39  When  the  monad  T  is  already  of  the  form  Ta  =  °(T'a)  for  some  type 
constructor  T'  (e.g.,  for  exceptions,  T'a  =  a  +  \),  a  slightly  simpler  construction  is 
possible.  Take  uj  =  T'( SK)  so  that  o  =  °lj  =  °(T'y)  =  T7,  <f>*t  =  let°  s  <=t  in  °((j)s),  and 
ip*  m  =  let”  r  <=  m  in  °(Ur).  (Here  (j)*  and  ip*  are  actually  two-sided  inverses.)  Then  we 
get  the  analog  of  Theorem  3.38  by  defining  reflection  and  reification  as  follows: 

HT(M)  =  /jK(X  k.k*M) 

[M]T  =  (Ar. let”  a  <=  out,r  in  r]a)*  ([M]A  (Aa.7](irpa)))  (N(i)=a) 

The  actual  ML  code  in  Section  4.5  takes  advantage  of  this  optimization  by  not  including 
an  explicit  suspension  in  the  definition  of  monads  like  T,  but  instead  having  it  implicitly 
inserted  by  the  CBV  elaboration  from  Section  2.1.6.  In  other  words,  the  type  constructor 
T  in  the  ML  signature  of  such  a  monad  actually  corresponds  to  the  T'  above,  so  that, 
e.g.,  ((oi  — y T(T2 ))v  =  ((cji))v  —y  0((T(j2 ))v  =  ((cti))v  ~^T(a2))v.  We  could,  however,  simply  use 
Theorem  3.38  directly  in  all  cases.  ■ 

We  have  thus  reduced  the  problem  of  implementing  a  language  with  monadic  effects 
for  an  arbitrary  definable  monad  T  to  that  of  implementing  a  language  with  reflection 
and  reification  operators  for  a  continuation  monad  with  an  answer  type  °ui  for  some  value- 
type  uj.  In  the  next  chapter,  we  will  show  how  this  can  itself  be  achieved  by  embedding 
the  continuation-effect  language  into  a  Scheme-like  one. 

3.3.6  Induced  relational  correspondence 

We  finally  show  how  the  relational  correspondence  between  Cs  and  C\  can  be  generalized 
to  the  case  where  the  base  language  is  itself  given  by  a  monadic  translation.  That  is,  we 
consider  the  language  where  we  take  1  as  the  distinguished  computation-type  constructor, 
while  °  and  its  related  operations  become  simply  additional  type  and  term  constructors. 
Corollary  2.29  showed  that  this  new  language  is  also  a  model  of  £0;  the  following  shows 
that  this  equational  characterization  extends  to  a  relational  one: 
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Proposition  3.40  Let  there  be  given  a  monad  relation  between  T  in  jCs  and  U  in  £; 
(Definition  3.26).  Then  the  relation  assignment  determined  by  the  monad  relation  is  a 
computation- extension  in  the  sense  of  Definition  3.20  for  ' -computations  in  the  languages 
(LfCf)  and  (LqU as  given  by  Definition  2.2f. 

Proof.  For  the  first  condition,  let  R  e  ARel cT  ,cv(aia')  be  a  relation,  and  let  a  R  a'; 
we  must  show  that  'a  ('R)  'a1 ,  i.e. ,  that  in  the  original  correspondence, 

['a]T  =  Tja  (' R)  ea  =  ['a][r 

and  that  follows  immediately  from  Definition  3.26(1). 

Similarly,  assume  that  Va  R.\  a1,  fa  ('i?2)  fa1  and  m  ('Rf  m! .  We  must  show  that 

let'  x  -<=  m  in  f  x  (' )  let1  x!  -<=  m!  in  f  x! 

in  the  new  correspondence,  i.e.,  that 

[let1  x  m  in  f  x\T  =  (Ax.  f  x)*  m  =  f*  m 

('i?2)  f'+m'  =  (Ax' .  f' x')+  m  =  [let1  x'  -<=  m!  in  f'x' ]c, 

in  the  original  one,  which  is  precisely  the  statement  of  3.26(2).  ■ 

3.4  Related  work 

The  study  of  relationships  between  direct  and  continuation  semantics  has  a  long  history. 
Early  investigations  [Rey74a,  ST80,  Sto81]  were  set  in  a  domain-theoretic  framework 
where  the  main  difficulties  concerned  reflexive  domains;  as  a  result,  these  methods  and 
results  were  closely  tied  to  specific  semantic  models.  On  the  other  hand,  Meyer  and 
Wand’s  more  abstract  approach  [MW85]  applied  to  all  models  of  simply-typed  A-calculi, 
but  did  not  encompass  computational  effects  -  not  even  nontermination. 

The  present  work,  while  formulated  in  a  simply-typed  setting,  and  using  mostly  ax¬ 
iomatic  reasoning,  is  nevertheless  closer  conceptually  to  the  domain-theoretic  results.  In 
particular,  it  explicitly  handles  general  recursion  in  computations  by  fixed-point  induc¬ 
tion,  and  should  extend  to  recursively-defined  types  without  too  many  obstacles.  (The 
initial  version  in  [Fil94]  was  based  on  the  Meyer- Wand  approach,  but  it  is  not  clear  how 
well  that  would  scale  to  ambient  effects  and  especially  recursion.) 

A  possible  correspondence  between  monads  and  continuation-passing  style  (CPS)  was 
conjectured  by  Danvv  and  Filinski  [DF90],  and  more  concretely  presented  by  Wadler 
[Wad92b],  (The  general  idea  of  using  a  monad  morphism  to  simulate  one  monadic  ef¬ 
fect  with  another  is  also  due  to  Wadler  [Wad90].)  However,  this  work  was  largely  in¬ 
formal.  Most  notably,  the  problems  with  reification  (needed,  e.g.,  to  express  handle  for 
continuation-based  exceptions)  in  a  typed  setting  were  not  addressed  at  all. 

Peyton  Jones  and  Wadler  [PW93]  probe  the  relationship  between  monads  and  CPS 
further,  and  Wadler  [Wad94]  analyzes  composable  continuations  from  a  monadic  per¬ 
spective,  but  in  both  cases  the  restriction  to  Hindley-Milner  typable  translations  ob¬ 
scures  the  general  correspondence;  properly  expressing  the  answer-type  parametricity 


3.4.  RELATED  WORK 


79 


in  a  simulation  of  general  monads  by  continuation-passing  requires  a  more  flexible  type 
system. 

Finally,  another  glimmer  of  the  connection  between  monads  and  continuations  can 
be  seen  in  Sabry  and  Felleisen’s  result  that  /^-equivalence  of  CPS  terms  coincides  with 
direct-style  equivalence  in  Moggi’s  computational  A-calculus  [SF93,  Mog89];  the  latter 
captures  exactly  the  equivalences  holding  in  the  presence  of  arbitrary  monadic  effects. 
While  this  does  not  by  itself  imply  that  any  monadic  effect  can  be  simulated  by  a  continu¬ 
ation  monad,  it  does  indicate  that  continuations  form  a  maximally  (but  not  necessarily 
most )  general  notion  of  effect. 


Chapter  4 

Implementing  Continuation-Effects 


In  this  chapter,  we  continue  the  simulation  of  effects  by  showing  that  a  language  with 
reflection  and  reification  operators  for  a  continuation  monad  can  itself  be  embedded  in 
a  language  with  a  more  traditional  set  of  effects:  Scheme-style  first-class  continuations 
and  typed  state. 

That  is,  in  the  previous  chapter  we  showed  that  continuations  are  in  a  precise  sense 
a  universal  effect  any  definable  monad  can  be  simulated  by  a  continuation  monad  with 
a  suitable  answer  type.  Now  we  show  that  this  universal  effect  can  itself  be  expressed 
in  terms  of  two  specific,  low-level  effects.  Thus,  we  can  program  directly  with  monadic 
effects  in  a  language  such  as  Scheme,  or  ML  with  continuations. 

The  development  consists  of  three  major  steps.  First,  we  re-express  reflection  and 
reification  for  continuations  in  terms  of  an  alternative,  more  operationally  motivated 
pair  of  control  operators.  These  implement  a  control  abstraction  known  as  composable 
continuations.  We  further  decompose  the  composable-continuations  operators  into  a 
standard  escape- operator,  an  abort- operator,  and  a  control  delimiter. 

Then  we  show  that  the  level-tags  (°  and  1  on  value-inclusions  and  lets)  introduced 
by  the  monadic  translation  are  actually  unnecessary  for  evaluation-purposes:  the  level- 
erasure  of  a  program  evaluates  to  the  same  result  as  the  original  one.  The  proof  involves 
another  set  of  logical  relations,  indexed  by  types  of  the  original  two-level  language,  and 
relating  original  and  level-erased  terms  at  each  type. 

Finally,  in  the  level-erased  language,  we  define  the  control  operators  in  terms  of 
Scheme-like  primitives.  The  key  step  here  is  to  re-express  the  sequencing  of  already 
continuation-passing  terms  in  meta- continuation-passing  style,  then  observe  that  the 
metacontinuation  is  used  in  a  single-threaded  way  throughout  the  translation  and  can 
hence  be  maintained  in  a  fixed  cell  of  the  store.  Again,  a  simple  logical-relations  argu¬ 
ment  shows  the  equivalence  of  the  original  definitions  of  the  control  operators  to  their 
escape-state  simulation. 

We  conclude  the  chapter  with  an  actual  implementation  of  the  construction  in  Stand¬ 
ard  ML  of  New  Jersey,  which  includes  language  support  for  first-class  continuations.  In 
addition  to  the  complete  code  implementing  monadic  reflection  and  reification  in  terms 
of  escapes  and  state,  we  show  a  few  simple  programming  examples.  In  particular,  we 
illustrate  how  definable  monadic  effects,  such  as  nondeterministic  or  probabilistic  com¬ 
putations,  fit  very  naturally  into  a  traditional  call-by-value  setting. 
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4.1  Continuation-reflection  and  composable  continuations 

For  convenience,  we  will  assume  that  all  signatures  in  the  following  contain  an  empty  type 
0  with  no  value  constructors.  Our  implementation  signature  Lf  =  L^'11  (i.e. ,  L0  with 
recursive  types  and  embedding-types)  certainly  does,  for  example  defining  0  as  /ia.  a  or  as 
an  embedding- type  with  empty  index  set.  We  need  not  require  that  0  has  a  counterpart 
in  the  specification  language  L0  as  well,  although  adding  it  there  would  be  unproblematic. 

Further,  for  any  computation-type  0  there  is  a  (unique)  function  from  0  to  0,  express¬ 
ible  as,  e.g.,  Xz.  Lp,  which  we  write  as  Vp.  In  fact,  0  and  V  are  simply  the  zero-ary  analogs 
of  sums  and  case  (except  that  we  do  not  require  a  Va  for  arbitrary  a)\  in  particular,  for 
any  monadic  translation  we  have  [0]T  =  0  and  [Vg  M]T  =  Vy}\  [M]T. 

Unlike  Chapter  3,  where  the  simulation  results  were  parameterized  by  the  fairly  com¬ 
plex  notion  of  a  definable  monad  (which  included  a  type  constructor  and  type-indexed 
families  of  term  constructors),  all  the  constructions  in  this  chapter  are  parameterized  by 
a  fixed,  closed  value-type  d.  Accordingly,  except  within  definitions  of  recursive  types 
with  /i,  we  only  need  to  consider  type-closed  types  and  terms. 

The  continuation-passing  translation  allows  us  to  define  a  wide  range  of  control  oper¬ 
ators  in  the  source  language.  We  have  already  seen  reflection  and  reification,  but  many 
others  are  possible.  In  particular,  we  have: 


Definition  4.1  Let  L  be  a  ell  signature  with  a  0-type,  and  let  uj  be  a  type  of  LA .  Then 
in  Lh (Definition  3.33),  we  defi,ne  the  operations 


r  h  M  :  (a  —t  ’0)  —t  '0  F  h  M  :  a j 
n-C M  :  Vv  r  AM  :  '() 

by  the  expansions: 


r  h  M  :  'Ll ) 
r  b  #M  :  °d 


V  ■  .\I  :  (a^°u)  -Vw 
V  <5  M  :  'a 


CM  =  n(\ka^  A  [M  (Aa“.  n(Xq'°^  A:a))]  (A2:0..  V^z)) 

AM  =  ii(\q°^C°M) 

#M  =  [M]  (\C.°r) 

S M  =  // ( A ka~>"a .  [M A:]  ( XC .°r)) 


The  operational  intuition  is  as  follows:  CM  ( escape )  invokes  M  with  a  representation 
of  the  current  evaluation  context  as  a  procedure  q  :  a  — >■  '0  that,  when  applied  to  a  value 
a  :  a,  will  abandon  the  then  current  context  of  evaluation  and  return  a  as  the  result  of 
CM,  e.g., 

C  (A q.  let1  z  <=  q3  in  •  •  •)  =  '3 

(regardless  of  what  happens  in  •••).  The  0- “returning”  q  can  invoked  in  a  context  ex¬ 
pecting  an  Vv'-typcd  result  by  writing  let1  z  q  a  in  V< a'  z.  C  thus  acts  very  much  like 
Scheme’s  call/cc,  except  that  the  M  must  explicitly  invoke  q  in  order  to  return  a  value 
from  C  M.  Each  variant  can  be  used  to  define  the  other,  however. 

AM  (abort)  immediately  terminates  the  current  computation,  returning  M  as  the 
answer.  Like  a  q  supplied  by  C,  it  can  be  used  in  combination  with  V  to  break  out  of 
any  computation-typed  context. 
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ffM  ( reset  or  prompt)  evaluates  M  in  an  empty  evaluation  context  and  returns  the 
final  answer  of  that  evaluation,  thus  delimiting  any  control  effects  M  might  have.  For 
example,  when  ui  =  t,  we  get 

#(let'  z^A5  in  7)  =  °5 

Finally,  SM  (shift)  captures  and  erases  the  current  evaluation  context  up  to  (but 
not  including)  the  innermost  enclosing  #,  passing  this  context  to  M  as  a  composable 
function.  For  example,  still  with  uj  =  we  have 

#(let'  x  y=  <S(AA:.let°  r |  y=  A:  4  in  let°  r2  <=  kr\  in  V2)  in  '(s;r))  =  °6 

Note  also  that  we  could  define  AM  =  S  (Xk°~*'w M) 

Although  probably  not  as  well  known  as  call/cc,  control  operators  like  S ,  A,  and  ff 
have  already  seen  a  fair  amount  of  study,  e.g.,  [Fel88,  SF90,  DF92,  Wad94,  Fil94,  GRR95]; 
we  will  briefly  compare  the  various  approaches  in  Section  4.6. 

For  reference,  and  since  we  will  need  it  later  (in  Definition  4.5),  let  us  note: 

Lemma  4.2  The  translations  of  the  derived  control  operator's  using  Definition  3.34  work 
out  to: 

\CM\k  =  Xk.[M]K  (Xa.  Xq.  ka)  (Xz.V z) 

[i«i.  =  M-mm*) 

[#M]„-  =  let'  o<=  in 

[5M]k  =  Xk.  [M]a.  (Aa.  let°  o  <=  ka  in  °(rfo))  (Xr..°((f>r)) 

Proof.  Straightforward.  For  example, 

[4M]k  =  lgK(\q.°M)\K  =  AA,-.let°  r  <=  \Xq.°M\K  (Aa.let°  o^ka  in  °(7°))  in  °(4>r) 

=  AA’.let"  r  <=  (A q.°\M\K)  (Aa.let°  o  <=  ka  in  °(rpo))  in  °(<pr) 

=  AA’.let"  r  <^=°[M]A.  in  °(4>r)  =  A k.°(<p\M\K) 

The  others  are  similar.  ■ 

The  reason  why  we  can  concentrate  on  the  composable-continuations  operators  in¬ 
stead  of  the  seemingly  more  general  fiK(~)  and  [-]K  is  the  following  property: 

Lemma  4.3  Shift  and  reset  form  a  complete  set  of  control  operators,  in  the  sense  that 
we  can  use  them  to  express  reflection  and  reification  as  follows: 

pK(M)  =  <S(AA:tW let°  r^Mk  in  V) 

[M]A  =  AA;“^ #(let'  a  <=  AI  in  let°  r  <=  ka  in  'r) 

and  get  equivalent  translations  under  [-]A. . 

Proof.  The  actual  translations  of  the  terms  contain  explicit  isomorphisms,  which 
clutter  up  the  equational  proofs.  It  is  thus  more  convenient  to  use  the  standard  direct- 
style  reasoning  principles  for  reflection  and  reification,  whose  soundness  with  respect  to 
the  [-]A -translation  was  established  in  Lemma  3.35: 
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S  (Xk.let°  r  <=  M k  in  V)  =  / i(Xk .  [(A k.  let"  r  <=  M k  in  V)  k]  (A r.°r)) 

=  n(X k.  [let"  r  <=  Mk  in  V]  (A r.°r))  =  y,(Xk.  let"  r  <=  Mk  in  [V]  (A r.°r)) 

=  n(Xk.  let"  r  ^  Mk  in  ( Xk.kr )  (A r.  °r))  =  n( Xk.\et°  r  <=  Mk  in  °r)  =  / i(Xk.M k) 
/'<•'/) 

AA;.#(let'  a  <^=  M  in  let"  r  <^=  ka  in  V)  =  AA;.  [let1  a  •<=  M  in  let"  r  <^=  A;a  in  V]  (A r.°r) 
=  AA;.  [M]  (Aa.  [let"  r  ^  ka  in  V]  (A r.°r))  =  AA;.  [M]  (Aa.let"  r  <^=  ka  in  [V]  (A r.°r)) 
=  Xk.  [M]  (Aa.let"  r  ^  ka  in  (A r.°r)r)  =  Xk.  [M]  (Aa.let"  r  <=  ka  in  °r) 

=  Xk.  [M]  (Aa.  Asa)  =  AA:.  [M]  k  =  [M] 


That  is,  reflection  essentially  captures  the  current  continuation  and  passes  it  to  M, 
while  reification  evaluates  M  in  a  delimited  control  context  containing  only  k.  This  simple 
reading  is  somewhat  obscured  by  the  explicit  lets  and  value-inclusions  used  to  coerce 
between  the  two  kinds  of  computation.  However,  when  we  eliminate  the  operational 
distinction  between  °  and  '  in  the  next  section,  the  two  mixed-level  lets  (binding  r)  can 
actually  be  replaced  with  just  M k  and  ka. 

Somewhat  surprisingly,  the  reflect-like  S  can  itself  be  decomposed  into  a  standard 
escape-operator  and  two  simpler  constructs: 


Lemma  4.4  S  is  definable  in  tenns  of  C,  fi,  and  A  by 

SM  =  C  (Ac“-!',°.  let'  r  <=  M  (Aa“.#(let'  £  <=  ca  in  V^z))  in  Ar) 

Proof.  As  in  Lemma  4.3,  we  can  use  direct-style  reasoning  for  the  actual  verification: 

C  (Ac.  let'  r  <=  M  (Xa.fi (\et'  z  4=  ca  in  V z))  in  Ar) 

=  [i(Xk.  [(Ac.  let'  r  <=  M  (Xa.fi (let'  z  <=  ca  in  V z))  in  Ar)  (Xa.y,(Xq.ka))~)  (Xz.Vz)) 
=  [i(Xk.  [let1  r  •$=  M  (Xa.fi(\et'  z  <^=  (Xa.  y(Xq.ka))  a  in  V  z))  in  Ar ]  (Xz.Vz)) 

=  n(Xk.  [M (Aa.#(let‘  z  <=  y(Xq.ka)  in  V^))]  (Ar.  [Ar]  (A^.V^))) 

=  fi(Xk.  [M (Aa.  [let1  z  <=  fi(Xq.ka)  in  Vz]  (Xx.°x))]  (Ar.  [ y(Xq.°r )]  (A z.Vz))) 

=  n(Xk.  [M (Aa.  [n(Xq.ka))  (X z.  [V z]  (Xx.°x)))]  (Ar.  (A q.°r)  (Xz.Vz))) 

=  y(Xk.  [M  (Aa.  (Xq.ka)  (A  z.  [V  z]  (Xx.°x)))]  (X  r.°r))  =  y,(Xk.  [M  (Xa.ka))  (A  r.°r)) 

=  n(Xk.  [M A:]  (A r.°r))  =  SM 


Here,  we  wrap  the  escaping  continuation  c  provided  by  C  in  a  control  delimiter,  making 
it  into  a  composable  function  that  can  be  passed  to  M.  Since  S  also  needs  to  erase  the 
continuation  after  capturing  it,  we  explicitly  abort  with  the  result  r  returned  by  M. 

Because  C.  A  and  fi  were  themselves  defined  in  terms  of  /jk(~)  and  [-]K,  in  principle 
it  does  not  matter  which  set  we  use  in  the  following.  Pragmatically,  however,  (C,A,fi) 
have  the  advantage  that  their  types  contain  no  negative  occurrences  of  °,  which  slightly 
simplifies  the  arguments  in  Section  4.2.  We  therefore  now  switch  attention  to  the  new 
set: 
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Definition  4.5  Let  L  be  a  ell  signature  with  a  0-type,  and  let  w  be  a  type  of  L*.  The 
signature  LK extends  L  with  a  computation-type  constructor',  associated  value-inclusion 
and  lets,  and  the  term  constructors  C,  A,  and  ff,  typed  as  in  Definition  f.l.  There  is  an 
evident  translation  from  LK~W  to  LR^t  given  by  the  statements  of  Lemmas  f.3  and  f.f. 

The  definitional  translation  [-]A.  from  LK to  IT  is  identical  to  the  one  for  LK from 
Definition  3.3 f,  except  that  the  clauses  for  /JK(-)  and  [-]K  are  replaced  with  the  clauses 
for  C,  A,  and  ff  from  Lemma  f.2. 

Note  that,  since  we  consider  complete  programs  to  be  terms  of  type  \  the  type  system 
ensures  that  all  control  effects  in  an  L h -program  occur  within  the  dynamic  scope  of 
some  ff. 

4.2  Level-erasure 

Between  Chapter  3  and  Section  4.1,  we  have  now  reduced  monadic  effects  to  shift/reset 
and  further  to  escapes,  abort,  and  reset;  all  dependencies  on  the  original  monadic  transla¬ 
tion  are  gone  from  the  translation  equations,  with  the  monad  simulation  being  performed 
entirely  by  expanding  T-reflection  and  -reification  into  simple  control  operators  and  com¬ 
ponents  of  the  monad-triple. 

However,  our  effect-enriched  language  Lf  still  has  a  significant  practical  limitation:  we 
need  to  explicitly  indicate  the  levels  on  all  value-inclusions  and  lets.  From  a  specification 
perspective,  this  is  reasonable;  with  general  reflection  and  reification  available,  we  must 
distinguish  properly  between  °-  and  '-computations  in  order  to  even  define  the  monadic 
translation. 

Moreover,  most  programs  can  actually  be  written  in  terms  of  '-computations  alone, 
with  uses  of  °  restricted  to  the  definitions  of  monad-specific  effects  from  reflection  and 
reification,  such  as  the  raise  and  handle  in  Example  2.26.  Thus,  for  particular  compu¬ 
tational  effects,  we  may  not  need  to  explicitly  expose  “-computations  to  the  language  as 
a  whole. 

On  the  other  hand,  if  we  are  to  provide  reflection  and  reification  for  arbitrary, 
programmer-defined  monads,  we  do  need  general  “-computations  to  be  directly  express¬ 
ible  in  the  language.  In  languages  such  as  Effect-PCF  (i.e. ,  our  L0),  where  computation- 
sequencing  is  already  explicit,  adding  level-annotations  to  all  inclusions  and  lets  may  not 
be  too  problematic.  But  in  an  ML-like  language,  implicitly  elaborated  into  Effect-PCF 
as  in  Section  2.1.6,  there  is  no  room  for  significant  effect-annotations  of  source  terms. 
And  fortunately,  as  far  as  program  evaluation  is  concerned,  the  levels  can  actually  be 
safely  elided. 

The  idea  is  to  view  °a  as  a  subtype  of  'a,  rather  than  as  an  entirely  separate  type. 
Membership  in  °a  then  becomes  a  semantic  property  on  values,  with  the  type  system 
guaranteeing  absence  of  effects  in  certain  terms,  but  not  playing  an  active  role  in  the 
actual  evaluation  process.  Accordingly,  we  now  define  a  new  language  with  a  unified 
notion  of  control-effects: 

Definition  4.6  Take  L\  to  be  Lfi  extended  with  an  empty  type  0  and  associated  V.  We 
further  define  the  set  of  L\  types  to  be  the  same  as  that  of  L1;  but  with  the  type  constructor 
replaced  by  a  new  constructor  ?. 
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When  oj  is  an  L*-type,  the  signature  LcvCu>  of  the  composable-continuations  language 
then  consists  of  Li  with  all  instances  of°  replaced  by  T  (so  in  particular,  for  computations 
we  now  have: 

F  b  M  :  a  F  b  Mi  :  'Pa1  T,x:ai  b  M2  : 
b  'M  :  Tn  r  b  letf  x  <=  M1  in  M-,  :  W2 

but  no  °- computations) ,  together  with  the  following  additional  term  constructors: 

F  b  M  :  {a  -)•  90)  ->•  90  F  b  M  :  u:  F  b  M  :  'u 

F  b  CM  :  Vv  F  •  .4.1/  :  '0  F  b  #M  :  bu 

We  can  define  a  translation  from  our  two-level  control-effect  language  into  the  unified 
one  by  simply  dropping  the  distinctions  between  the  levels: 

Definition  4.7  The  level-erasure  translation  |-|  is  defined  as  follows.  First,  for  any 
L\-type  a,  [«|  is  the  L*-type  obtained  by  replacing  all  occurrences  of  °  and  '  in  a  with  b 

|°ai|  =  I'aj  =  f|o| 

with  the  other  type  constructors  unaffected.  For  terms,  level- erasure  likewise  conflates  all 
uses  of°  and  1  into  f  (e.g.,  \°M\  =  \'M\  =  f\M\),  and  maps  the  constructors  C,  A,  and  ff 
to  their  counterparts  from  Definition  f.6. 

It  is  easy  to  see  that  ifT  b  M  :  a  in  I ,  then  |F|  b  \M\  :  | ck |  in  L{  |u|. 

We  can  also  give  a  definitional  translation  of  the  one-level  language: 

Definition  4.8  Let  lo  be  an  L\-type.  We  then  define  the  continuation-passing  translation 
[“If  from  LC[Cu>  to  Lf  as  follows.  First,  let  the  auxiliary  [-]F.  on  types  be  the  syntactic 
expansion  of  fa  into  — >■  °a)  — >■  °a,  and  take 

w  =  //a.  . 

We  also  write 


:  Mf,  ^  u  =  raMa.[%a  arid  if  :  w  A  =  unrolla.M-a 

for  the  associated  isomorphisms.  The  translation  of  types  is  then  given  by: 

[’’“If  =  (M§f  °b>) 

(with  the  other  type  consti'uctors  not  affected).  Correspondingly,  the  non-identity  clauses 
of  the  term  translation  are: 

VMh  =  \k.k[M]j? 

[letT  x  <=  Mi  in  M2]w  =  Xk.{Mi]w  {Xx.{M2]w  k) 

[CM]jt  =  Xk.{M]w  (Xa.  Xq.ka)  (Xz.V z) 

{AMh  =  M-fHMh) 

[#M]?  =  AA:.  let°  o  <=  [M]^  (Xr.  °{fi>r))  in  A:  {fio) 

As  usual,  this  translation  is  easily  seen  to  be  type-preserving:  if  F  b  M  :  a  in  if  (  then 
[F]f  b  \M\e  :  [a]*  in  V>. 
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We  can  now  state  our  goal  concretely:  we  want  to  show  that  the  original  [-]K- 

translation  from  Definition  4.5  is  equivalent  for  evaluation  purposes  to  a  level-erasure 

followed  by  the  [-]A-translation.  To  establish  this  equivalence,  we  will  define  a  collection 
of  relations  between  the  types  arising  from  the  two  translations.  The  key  ingredient  here 
is  a  suitable  relational  action  of  the  type  constructor  °  in  the  two  translations: 

Definition  4.9  Let  there  be  given  a  relational  corr'espondence  between  two  interpreta¬ 
tions  of  Li,  with  a  computation- extension  of  relations  Re^-°R  (Definition  3.20).  Then 
for  any  relation  R  £  ARel(o:,  of),  we  define  the  relation  °R  £  CARelfW,  [of  -A  °S ;)  -A  °uf) 
by: 

m  (°R)  u 

-<=>  Veto  type£M ,  O  £  ARel(aio,  O).  A k.  let°  x  <=  m  in  kx  ((R  -A  °0)  -A  °0)  u 

•<=A>  Veto  typeL/< ,  O  £  ARel(a:o,  0),k  :  a  -A  Wo,  k1  :  a1  -A  °lu. 

(Va  R  a1,  ka  (°0)  k1  a’)  =A  let°  a  A=  rri  in  ka  (°0)  uk1 

(Note  that  this  is  essentially  the  monad  relation  from  Lemma  3.31,  with  T  taken  as  the 
identity  monad,  7  =  a),  o  =  °a ),  and  =  fi*  =  id.  That  is,  we  are  using  a  continuation 
monad  to  simulate  a  trivial  notion  of  focus  effects.) 

We  can  now  define  our  system  of  relations: 

Definition  4.10  Let  u)  be  an  L\-type,  take  0  =  [o;]A,  (Definition  3.34)  and  V  =  UML- 
(Definition  4-8),  and  let 

A~  £  ARel(cj,cj) 

be  an  admissible  relation  on  final  answers;  for  the  moment  we  leave  its  definition  unspe¬ 
cified.  For  any  type  a  of  L\,  the  relation 

Fa  G  ARel([a]K,  [|«|]A) 

is  then  given  in  the  usual  way  for  base  types,  sums ,  products,  and  functions.  For  the 
remaining  L\-type  constructors,  we  take: 

z  Ao  ^  -  01  z  false 

s  Ask  s'  s  (S)Vn(i))  s'  3z  £  domH,fl  F$(i)  a' ■  s  =  i n*a  A  s'  =  in*  a' 

m  >—a  u  -<=>  m  (°Aa)  u 
u  A'  a  u  u  (( Aa  u 

VA:,  k' .  (Va  Aa  a'.ka  (>)  k'a')=>uk  (>)  u' k' 

It  is  easy  to  see  that  all  A0  are  admissible  (we  can  view  Ao  as  being  defined  by  an 
inverse  image  of  constant  functions:  Ao  z'  -<=A>  0  zr  1  ;  for  Ask,  see  Lemma  A. 10(3)), 
and  that  A°a  and  >-<a  are  also  computation-admissible. 

The  representation  of  a  W- value  in  the  [|-|]A -translation  will  always  be  of  the  form 
AA:.let°  x  <=  m'  in  kx  for  some  m',  and  thus  in  particular  must  be  parametric  in  the 
answer  type.  Hence,  we  could  define  A°a  without  committing  to  any  particular  relational 
interpretation  of  answers:  A  does  not  occur  in  the  definition  of  A°a  from  Aa. 
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On  the  other  hand,  for  >-<Q  the  identity  of  the  answer  type  is  explicitly  exposed  to 
the  source  language,  because  A  takes  an  arbitrary  value  of  type  u  to  be  an  answer,  while 
ff  allows  answers  to  be  inspected  as  (control-effect-free)  computations  of  type  u j.  Thus, 
if  we  want  to  relate  terms  containing  A  and  ff,  we  cannot  choose  A  arbitrarily:  it  must 
match  up  with  Fortunately,  this  circular  dependency  can  be  resolved,  because  of  the 
following  important  result: 

Theorem  4.11  Let  F  and  F'  be  type  constructors,  and  let  *  be  a  formal  relation  con¬ 
structor,  built  out  of  (1)  the  standard  relational  actions  of  L\-type  constructors,  (2)  con¬ 
stant  admissible  relations  (computation- admissible  for  computation-types) ,  and  (3)  the  re¬ 
lation  constructor  °|  so  that  *  maps  any  relation  R  £  ARel(«,  a')  to  *R  £  ARel(Fa,  F'a'). 
Then  *  has  an  invariant  relation  fiR.  * R  £  ARel(/ia.  F a,  /ra.  F'a),  such  that 

a  (fjR.'R)  a'  -<=>  unroll aFaa  * (fj.R.*R)  unrolla  F/aa' . 

Proof.  See  Corollary  A. 20  in  Section  A. 4.  ■ 

Form  this  we  immediately  obtain: 

Lemma  4.12  There  exists  an  admissible  relation  V  £  ARel(u),u))  such  that 

o  A  o'  -<=>-  ipo  if  o' 

(where  is  defined  in  terms  of  A  by  Definition  f.10). 

Proof.  The  existence  of  A  hinges  on  being  defined  from  it  using  only  the  operations 
enumerated  in  Theorem  4.11.  Thus,  we  can  directly  take  A  to  be  the  invariant  relation 
for  the  action  *  mapping  A  to  m 

Note  that  even  though  ui  is  genuinely  recursive  when  oj  contains  any  computation- 
type  constructors,  the  circularity  in  the  definition  of  A  still  only  occurs  when  uj  contains 
a  '.  Otherwise,  Fa  becomes  just  an  unparameterized  definition  by  induction  on  a,  and  in 
particular  does  not  depend  on  A-  We  can  then  simply  take  Lemma  4.12  as  the  definition 
of  A;  there  is  nothing  to  prove  in  that  case. 

We  can  now  state  the  correctness  result  for  level-erasure: 

TfCC  f 

Lemma  4.13  IfT  h  M  :  a  is  a  term  of  L[  and  a  >~r  o'  then  \M\aK  Fa 
Proof.  The  proof  is  by  induction  on  M.  The  interesting  cases  are: 

•  Case  °M.  To  show: 

•PC  wv[|m|]£ 

I.e.,  that  for  any  O  and  k  (ya  — >■  °0 )  k ', 

let°  a  <=  °{MfK  in  ka  IfO)  k'[\M\j^ 

With  a  simplification  of  the  LHS,  this  reduces  to  showing 

klMZ  CO)  k'\\M\% 

which  we  get  immediately  from  IH  on  M  and  the  assumption  on  k  and  k' . 
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Case  let°  x  ■$=  Mi  in  M2  :  °a2.  To  show: 

let-  x  <=  [M,]'  in  [MJ"  A*'.  [IA/,1]^  (Xx.  l\M2\%k') 

That  is,  for  any  O  and  A:  (ya2  °0)  A:',  we  must  show 

lef  o2  *  (lef  x  *  [Mi]'  in  [A/2]')  in  ka2  fO)  [|M,|]£  (Ai.[|M2|]£  *') 

Again,  by  a  simple  rewriting  of  the  LHS,  this  is  equivalent  to 

let”  x  <=  [Mi]£  in  (Ax.  let”  a2  <=  [M2]^,  in  ka2)x 
(”O)[|M1|]J(A^.[|M2|]^0 

By  IH  on  M,  and  the  definition  of  >--ai,  it  suffices  to  show  that 

Vai  >-ai  a[.  (Ax. let”  a2  •<=  [M2]£  in  A:a2)a1  (°0)  (Ax.  [|M2|]^  k')^ 
i.e. ,  that  for  all  a\  >-ai  a\ . 

let”  a2  <=  \M2YK{ai/x}  in  ka2  (°0)  {\M2\j^{a'i/x}  k' 

And  that  follows  immediately  from  the  IH  on  M2,  with  extended  substitutions 
(<r,  oq/x)  and  {a',a\/x). 

Case  let”  x  <=  Mi  in  M2  :  ‘a2.  To  show: 

A*,  lef  x  -s=  [M,]'  in  [M2fKk  y.a,  Afc'.[|Mi|]£  (Xx. [\M2\% *') 

That  is,  for  k  (yan  — >■  V)  A:', 

lef  x  ■<=  [Mi]'  in  [M2]'X  (>)  [|M,|]J  (Ax.  [|M2|g  *') 

Again,  by  a  simple  rewriting  of  the  LHS,  this  is  equivalent  to 

let”  x  4=  {MiYk  in  (Ax.  [M2]'  k)x  (>)  [| Mi\%  (Ax.  [|M2|]£  A:') 

As  above,  by  IH  on  Mi  and  the  definition  of  ,  taking  a0  =  0  and  O  =  N,  it 
suffices  to  show  that 

Va-i  a’i.  (Ax.[M2^A:)a!  (>)  (Ax.  [|M2|]^  A:7)  a[ 

which  follows  immediately  from  the  IH  on  M2,  with  extended  substitutions  ( a ,  oq/x) 
and  (<r ka'i/x). 

Case  A.M.  To  show: 

I.e.,  that  when  q  (>-0  — >■  °tz)  q'  (vacuously  true  for  any  q  and  q')  then 
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By  property  3.20(1)  of  “V.  it  suffices  to  show  that 

mrK  >=  Hma 

which  by  Lemma  4.12  is  equivalent  to 

and  that  we  get  by  IH  on  M  after  cancelling  out  the  isomorphisms. 

•  Case  #M.  To  show: 

let°  o  -<=  \M\aK  (A r.°{(j)r))  in  °{ipo) 

Xk'.let°  o'  <$=  (Ar'.  °(J>r'))  in  k'  (ip o') 

I.e.j  that  for  any  O  and  k  (y^  —VO)  k', 

let°  x  <=  (let°  o  <=  {MV  (\r,°(<f>r))  in  (iro))  in  kx 
(°0)  let°  of<=[\M\j%  (A r'.°(^r'))  in  k'(iPo') 

which  simplifies  to 

let°  o  <$=  \M\aK  (A r.°(<f>r))  in  k(tpo) 

(°0)  let"  o'  <=  (A r'.°((j)r'))  in  k'(ijjo') 

By  definition  of  y  and  the  assumption  on  k  and  k ',  we  have 

Vo  y  o' .  k  ( i'o)  (°0)  k  (Uo) 

so  by  3.20(2),  it  suffices  to  show  that 

[MJJ(Ar.-(0r))(>)[|M|g(Ar'.-(0r')) 

By  IH  on  M,  we  have  \M\aK  y<m  so  we  only  need  to  show  that 

Vr  yw  r'.  °{(f)r)  (V)  °{(f)r') 

which  follows  from  3.20(1)  if  we  have 

V?1  r' .  (f>r  y  (f)r' 

and  that  is  again  an  immediate  consequence  of  the  definition  of  V-  as  in  the  case 
for  AM  above. 

•  Case  C  M.  Simple  -  same  translation  on  both  sides. 

•  Case  Vp  M.  To  show: 

lMTK  Hiailt  1\m\Tk 

But  by  IH  on  M,  \M\aK  so  this  case  can  never  actually  occur  (indeed, 

there  are  no  closed  values  of  type  0). 
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•  Case  irijM.  To  show: 

in,  MI-  i-EK  in,[|M|g 

By  IH  on  M,  we  have  [M]^.  y$(i)  so  we  get  the  result  directly  from  the 

definition  of 

•  Case  outdjM.  To  show: 

outd i{MfK  ym+i  outdi[|M|]J 

I.e.,  that 

outd,  A/  "  {Nm  +  !)  outc|i[lMl]J 

By  IH  on  M  and  the  definition  of  [A/]"  =  in*/  a  and  [|M|]^  =  in,;/  a'  for  some 
i'  G  dom  K  and  a  >~n(?7)  cl'.  There  are  two  possibilities: 

—  i'  =  i.  Then  by  definition  of  +r  we  have 

outd,;  (in,; a)  =  ini  a  (>-Np)  +  1)  ini  a'  =  outd,;  (in,; a') 

—  i'  ^  i.  Then,  again  by  definition  of  the  relational  actions  of  +  and  1, 

outd,;  (in,;/  a)  =  inr  ()  +1)  inr  ()  =  outd,;  (in,;/  a') 


4.3  Composable  continuations  from  escapes  and  state 

We  now  only  have  to  implement  a  one-level  language  with  escapes,  prompts,  and  abort, 
specified  by  a  simple  continuation-passing  transform.  Since  we  may  want  to  perform  the 
continuation-passing  translation  anyway,  e.g.,  for  cps-based  code  generation  [App92],  we 
seem  to  be  on  the  right  track.  On  closer  inspection,  however,  the  translation  does  not 
quite  produce  “proper”  continuation-passing  terms:  there  is  still  a  little  bit  of  explicit 
sequencing  left  in  the  output. 

Recall  the  equations  for  [-]F  from  Definition  4.8.  The  problem  is  with  A.  and  espe¬ 
cially  with  #,  which  introduce  an  explicit  notion  of  sequencing  of  already  continuation¬ 
passing  terms.  By  a  stroke  of  good  luck,  however,  we  can  express  this  sequencing  in 
terms  of  another  standard  effect,  namely  state. 

The  key  idea  is  to  eliminate  the  remaining  traces  of  explicit  sequencing  by  performing 
another  continuation-passing  transformation,  using  a  new  metacontinuation  7  to  keep 
track  of  the  nested  "-computations.  That  is,  we  take  the  implementation  interpretation  of 
ambient  effects  to  also  be  given  by  a  continuation  monad.  (We  do  not  constrain  the  answer 
type  of  this  monad,  so  we  retain  the  full  range  of  possible  ambient  computational  effects.) 
While  this  may  at  first  seem  to  move  us  farther  away  from  a  direct  implementation,  we 
will  see  that  the  “properly  continuation-passing”  terms  are  effectively  unaffected  by  this 
second  translation,  while  the  translations  of  A  and  #  change  in  a  useful  way. 
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Definition  4.14  In  L( ,  let  there  be  given  a  computation-type  6  of  ultimate  answers;  we 
will  often  abbreviate  a  — >■  6  as  -<a.  We  then  define  [-]c  :  Lf  — >■  V(  to  be  the  translation 
expanding  °- computations  into  continuation-passing  with  answer  type  6,  i.e., 

[  alc  =  (Nc  0)  0 

l°M\c  =  X  7. 7  [M]f, 

[let°  x  7=  M1  in  M2jc  =  Xy.  {Mi]c  (X'x-  [M2]tf  7) 

(with  other  type  and  term  constructor's  unaffected  as  usual). 

We  also  define  a  new  continuation-passing  translation  of  if  (  .  where  the  answer 
type  is  itself  explicitly  a  type  of  continuation-passing  computations  (as  opposed  to  the 
unspecified  notion  of  ambient  effects  in  °lu): 

Definition  4.15  Let  lo  be  an  L\-type,  and  take  lo  =  n a.  [w]A_a  with  isomorphisms 
&  =  rolla.M-_a  and  ijA  :  u>  M  =  unrolla^j-  ^ 

We  then  define  [-]K«  :  Lf[Cul  — >■  Lf  as  follows: 

rM]Ku  =  Xk.  A7.  A:  [M]ku  7 

[[let T  x  <=  Mi  in  M2]Au  =  Xk.  Xy.  [Mi]a.u  (Xx.Xy1.  [M]A.U  ky)y 

[CM]au  =  Xk.Xy.  [M]au  (Xa. Xq. Xy'. kay')  (Xz. Xy".Vzy"):f 
[AM}kU  =  Xq.  Xy.  7  (cf)u  [M]au  ) 

[#ML-  =  Xk.Xy.  [M]au  {Xr.xy_.y_ {fur)){Xo.k{yPo)y) 

Note  that  all  but  the  underlined  occurrences  of  7  can  be  ^-reduced  away,  so  the  trans¬ 
lations  for  value-inclusions,  lets,  and  escapes  form  a  completely  standard  continuation- 
passing  transformation. 

It  is  also  easy  to  see  that  this  translation  consolidates  the  two  nested  continuation- 
passing  translations  into  one: 

Lemma  4.16  For  any  type  a  ofI.(<  .  [[o]A]c,  =  [o]Au  and  for  any  term  M ,  [[M]A]C,  = 
[M]au  (in  the  predomain  interpretation  of  Lf). 

Proof.  The  only  complication  is  the  type-recursion  in  the  definition  of  the  translations. 
Recall  the  key  cases: 

•  {'ah  =  where  u  =  /ia.  [w]A.a. 

•  where  lo  =  /ia.  [cj]A_a. 

•  Mo  =  K4  “L  =  nnWr 
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We  first  strengthen  the  relationship  for  the  type  translation  to,  for  any  o  of  Lf, 


(A  — 

1 


(*) 


The  proof  of  (*)  is  a  simple  induction  on  ct;  the  only  interesting  case  is 


HMkJc  =  [(Hf„  -a 
-  (N/-Wc  -a  Mo) 


o]0  ~  (IHk,, 
Mo  =  kMc  H 


Now,  first  take  o  =  °a  in  (*)  to  get 


Mo)  -A  Mo 
—  I 


Me  =  MMa]c  =  /*»•  [NkJc  =  /ia-  Hiq-alp  =  /'»■  M/T_a  =  * 

and  then,  with  o  =  °uj, 


Given  the  equalities  on  types,  the  equality  on  terms  is  completely  straightforward. 
The  cases  for  value-inclusion,  let,  and  escape  are  immediate  since  their  |-]K -translations 
do  not  contain  any  sequencing;  we  obtain  the  result  by  simple  ^-conversion.  For  A  and 
ff,  we  use  that 


[0-^0  c  —  [rolla.[wj—  MJC  —  roMa.[[wt|f -„]o  1^1  o  —  r°Ha.[w]A  iMlc 


and  analogously  for  p .  Then,  for  example, 


f[M]o 


UAMhclc  =  =  A(?-A7-7  (<l>n  UMJkJc)  =  Ar/.A7.7(M[M]Ku) 

=  [7lM]Ku 


4.3.1  Re-tying  the  recursive  knot 

Our  metacontinuation  translation  [-]A.U  was  derived  directly  from  the  original  [-]A. 
However,  to  match  it  up  with  he  state-passing  translation  later,  we  first  need  to  relate 
[— ]Au  to  an  equivalent  formulation,  using  an  isomorphic  answer  type: 

Definition  4.17  Let  q  =  pa'.  a,  with  isomorphisms 

<T  :  ^  S  =  rol|a'.  K  ^  and  fin  :  q  ^  =  unrolla/._M-  &/ 

Then  define  [-]/fn  to  be  the  continuation-passing  translation  with  answer  type  and 
with  translation  equations  for  escape,  abort  and  reset  now  reading: 

[CM]A.n  =  Xk.Xg.\M\Kn(Xa.Xq.Xg'  .kag')(Xz.Xg"  .V  zg")g 
[AM]k n  =  Xk.Xg.  i:"g  .1/  A- 

[#M]An  =  Xk.Xg.  [M]A,n  (Ar. Xg'.yAg'r)  (cjA  (Xa.kag)) 

It  should  be  intuitively  plausible  that  this  definition  is  equivalent  to  the  one  in  Defini¬ 
tion  4.15  above;  we  state  this  precisely  in  Corollary  4.22  below,  to  which  one  may  proceed 
without  loss  of  continuity. 


From  Section  A. 3,  we  include: 
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Definition  4.18  The  functorial  action  of  Li-type  constructors  on  isomorphisms  is  given 
as  follows,  so  that  for  any  (p  :  a2,  4>a .a(<p)  :  a{ai/a}  -A-  o{a:2/a}  and  W^y{ip)  : 

/5{oi/a}  — >  (3{a2/a}: 

$a.a(<^)a  =  ( pa 

=  n 
=  () 

$l.aixa2{p)p  =  ($a.Q1(^)(fstp),$a.a2(^)(sndp)) 

Ta.O {<p)z  =  ~ 

<f)a.Q!l+Q!2  =  case(s,ai.inl  ($a.ai(<^)ai),a2.inl  ($a.a2(^)a2)) 

$Len(<p)s  =  case(s,z.a*.  ini(4>a.KW(^)aj)) 

<K.AT)I>  =  %  Av)b 

'K.-nlv)'"  =  let0  X  m  in  °($La(^)^) 

^Li(^)o  =  () 

'I,a.  ;,x(;..(r  )/'  =  ('J'a./31(^)(fstp),^L/g2(^)(sndp)) 

9  =  Xx.'Slpiv)  {g(^la(tp^1)x)) 

We  then  take  advantage  of  the  fact  that  our  chosen  solutions  to  recursive  type  equa¬ 
tions  are  unique  up  to  isomorphism,  so  that  in  particular  it  does  not  matter  where  we 
break  up  the  recursion  when  defining  a  pair  of  mutually  recursive  types: 

Lemma  4.19  Let  F  and  G  be  type  constructors  of  Li  (not  necessarily  covariant),  and 
let  a  =  pa.F(Ga)  and  a'  =  pa' .  G(Fa')  be  the  solutions  to  the  corresponding  recursive 
type  equations.  Then  in  the  predomain  model,  there  exists  an  isomorphism  \  :  Ga  a' , 
which  further  satisfies  the  following  two  (equivalent)  coherence  equations: 

x:  Ga  b  rolla'.G(Fa')  ($a'.G(Fa')(x)  ($a.Ca(  Unrolla.F(Ga) )  •?) )  =  :  a' 

y:a'  h  Ta.Ga(r°Ha.F(Ga))  (®a'.G(Fa') (X  1 )  (  unr°ll  a'.G(Fa')  V) )  =  X  1  U  '■  Ga 

Proof.  See  Lemma  A.  14  in  the  appendix.  ■ 

In  our  case,  we  obtain  from  this  the  following  instance: 

Lemma  4.20  There  exists  an  isomorphism  x  ■  ~^Co  -A-  g.  This  induces  for  any  type  a  of 
Li°w  an  isomorphism  Ta  :  [a]Ku  A*  [ar]Kn  =  Ta'.[a]^  ,  (x),  and  moreover 

g:g,r:  [w]^  h  x~M<T0  =  fng{Tur)  :  6 

Proof.  Define  the  type  constructors  Fa!  =  [cj]^  ,  and  Ga  =  ->a.  Then  we  have 

Co  =  pa.  [wjg_a  =  pa.  F(Ga)  and  c,  =  pa'.  =  pa'.  G(Fa') 

We  thus  get  the  isomorphism  :  -i Co  — >■  directly  from  Lemma  4.19.  Moreover,  we  can 
write  Yw  =  Tv, Fa'  f ) -  Now,  first  note  that 
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-,a(ip)hx  =  ^l_a^g{ip)hx  =  A?)  (h  =  id(/i($a.Q(<^  ^x)) 

=  h($l  a((p^1)x) 

And  then,  using  the  second  form  of  the  coherence  equation  from  4.19,  we  get 

x^g^r)  =  4>L.a(<n  a,  (x1)  (rg)]  (ro 
=  [<^M^a,  or1)  (rg)]  (4>ia  m  (ro  =  or1)  (rg)}  (r  (ro 

=  ^a'.^uffw  (r1)(rg)r  =  rg(K'.MW^,  (x)C  =  r g(Aujf) 


Because  the  translations  from  Definitions  4.15  and  4.17  are  both  continuation-passing 
translations  with  isomorphic  answer  types,  they  are  very  closely  related:  instead  of  the 
usual  logical  relation,  we  get  a  simple  equational  correspondence: 

Lemma  4.21  Let  T  =  (aq:  aq, . . . ,  xn:  an),  and  let  us  write  Tr  for  the  substitution 
(TQl  xi/xi,  . . . ,  TflVi ./•„ /.r:„).  Then  for  any  Lclc~' -term  T  b  M  :  a, 

T„  [M]k.  =  [M]  £ 

Proof.  The  cases  for  the  standard  terms  (products,  sums,  and  functions)  are  straight¬ 
forward.  For  example,  for  abstractions  and  applications,  we  have 

Tq_>./3  {\x.M}ku  =  \a.  Tg  ((\x.  [M]ku  )  (TQ 1  a))  =  \a.  (Xx.  Ty  [M]Au )  (T^1  a) 

'A  Xa.  (Xx.  ' )  (T„  1  a)  =  \a.[M}lP^x/x{T-1alx}  =  Aa.  [M]^T“  (T“  ' a)/x 

=  A  =  (A  x.{MjKn)rr  =  [A  x.MJll 

T/3  {Mi  M2]kU  =  T yilMihu  [M2]*„ )  =  (A a.  T /j  a))  [M2]A.U 

=  (Xa'.Tp  ([MJa.u  =  (T^  (Ta  [M2]A.U) 

=  lMljlrn  [M2]^  =  ([MiJjjn  [M2]a n)^  =  [M1 

For  computations,  let  us  first  name  the  induced  isomorphisms  on  meta-computations 

7r  : -i-iw  ^ -i?  =  $i._,a(x)  and  tt^1  :  -f.r  -i-$  -  $L^a(x_1) 

The  value  isomorphism  for  computations  then  becomes: 

a  (X)u  =  ^.([«]k  a  — ^-ia)— f-ia(x)  u 

=  \hNC  M("rl.W^  .  a(\  ')/■•)) 

=  Xk.ir(u  (Xa.  4,L-.a(x_1)  (k  (x) a))))  =  Xk.n  ^(Xa.rr^1  (k(Taa)))) 

With  this,  the  cases  for  inclusion  and  let  are  also  simple,  e.g., 

Tv,  [W]AU  =  Tv,  [A k.k  {MIkIc  =  (A k.k{MjKu ) 

=  A k.  tt((A k.  k  [M]a u  )  (Xa.  t r-1  (k  (T ao))))  =  Xk.  n  (t^1  (k  (Ta  [Af]**))) 

=  Xk. k  (Tq  [M]au )  *  A k.klMfKL  =  [WT]p 

The  interesting  cases  are  for  A  and  #,  which  actually  depend  on  the  answer  type. 
Here  we  need  to  expand  the  7r  and  7r_1, 

^f  =  ^r&(x)f  =  \g.f(x^19)  and  tt^1  f  =  $L-na(x_1)  /  =  A7-  /  (X7) 
in  Tv,  to  get 

T *au  =  Xk.  Xg.  u  (Xa.  Xj.  k  (TQ  a)  (xx))  (x^1 9)  ■ 

We  then  check: 
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DolAM]KU  =T,o(A(/.A7.7(^[M]kU)) 

=  M-M-X  1  g  {(f>u  {MjKu)  =f  Xq.Xg.^giT^lMjj.u)  =  Xq.  Xg.ipn  g  [M]£E 
=  l-AMjl? 

where  the  step  marked  with  f  uses  the  coherence  equation  from  Lemma  4.20. 

For  reset,  the  calculation  is  a  little  more  involved,  since  here  we  do  not  simply  discard 
the  continuation: 

=  T.w[A*.lef  o^M(Ar.°(^ur))  in  k(^o)jc 
=  Tt[J(AA:.A7.[M]Ku  (Ar.  Ay'. 7'  (fur))  (Ao.  k  (^u  0)7)) 

=  A  k.  X  g.  {M}k  u  (Ar.  A7. 7  (<£u  r) )  ( Ao.  k  (Tw  (^u  o) )  (x  (x_1  g) ) ) 

=  Xk.Xg.  M  Ki-.  (Xr.X^' -x'  (4>ur))(Xo.k(TUJ  ( Vo))g ) 

=  X  k.  X  g.  [M]  A.  u  ( Ar.  A7. 7  (</>ur))  (Ao.  (Xr.krg)  (Tw  (^u  o) ) ) 

=  Xk.Xg.  {M]Ku  (Ar.A7.x~1  (X7)  ('TO)  (Ao.'0n  (<£n  (Xr.krg))  (Tw  (^uo))) 

=t  Xk.Xg.  [M]a.u  (Ar.  Xj  Apn  (77)  (Twr))  (Ao.x-1  (0n  (Xr.kr g))  (cf>u  (ipu  o))) 

=  Xk.Xg.  [M]ku.  (Ar.A7,.^n(X7/)(Twr))(x_1(0n(Ar.A:rg))) 

=  Xk.Xg.  (Ttw  [M]a.u)  (Ar. Xg'.ipng'r)  (cjf  (Xr.kr g)) 

-  A/c-Ac^M]^  (Xr.Xg  aC g  r)((jf  (Xr.kr g))  = 

where  again  the  f  marks  two  applications  of  the  coherence  equation.  ■ 


We  can  now  state  the  observable  consequence  of  the  above  result,  expressed  using 
only  constructs  of  Lf,  i.e. ,  without  the  “helper”  isomorphisms  and  YQ: 


Corollary  4.22  Let  M  be  a  closed  LC{Cu; -ter  m  of  type  V.  Then  for  any  a0  :  9  andp  :  l^9, 
[M\k u  (Xn.Xy'.pn)  (Xo.a0)  =  [M]A,n  (Xn.  Xg'.pn)  (<fin  (Xr.a0)) 


Proof.  Simple  equational  verification,  using  Lemma  4.21  (with  empty  T),  Y,  = 
<Fa'.t(x)  =  id,  and  the  coherence  equation: 

\M\k  n  (Xn.Xg'.pn)  (fn  (X  r.aQ))  =  (Th  [M]A.U  )  (Xn.  Xg'.pn)  (<fa  (X  r.a0)) 

=  {MjKu  (Xn.Xy.[X7i.Xj.pn](TLn)(xy))(x^1(4>a(M.ao))) 

=  (Xn.Xy .p(TLn))  (Xo.x^1  (fn  (Xr.a0))  (fu  (i/P  o))) 

=t  lMjK»  (An.  Ay' .pn)  (XoApn  (fa  (X r.a0))  (Yw  (</>uo))) 

=  [M]a.  u  (A?^.  Xg'.pn)  (Ao.  (Ar .  o0)  (Yw  (7pu  o)))  =  [M\K  u  (An.  Xy'.pn)  (Xo.a0) 


Although  this  corollary  may  at  first  appear  too  specialized,  it  actually  covers  exactly 
what  we  need.  In  particular,  if  M  is  a  term  without  escaping  effects,  it  must  be  equivalent 
to  an  included  numeral,  rn  in  the  [-]A.U -translation,  and  we  get: 

[M]A.u  (An.  A  x' -pn)  (Xo.ao)  =  fn]A-u  (X?i.  Xj.pn)  (Xo.ao) 

=  rn]xn  (An.  Xg'.pn)  (<fa  (Ar.oo))  =  [Xk.  Xg.k 77, g\  (X71.  Xg' .p 71)  (4>n  (Xr.cio))  =pn 

On  the  other  hand,  if  M  actually  invokes  the  metacontinuation  (through  an  A  not 
protected  by  an  enclosing  #),  both  translations  return  the  “error  answer”  a0. 
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4.3.2  The  continuation-state  language 

Let  us  now  assume  that  we  have  available  a  language  with  Scheme-like  escapes  and  state 
as  the  effects.  For  simplicity,  we  consider  the  state  to  consist  of  only  a  single,  typed  cell 
(additional  state  could  still  be  accommodated  by  choosing  9  appropriately): 

Definition  4.23  Let  a  be  an  L\-type.  Then  the  signature  LcvSa  of  the  continuation-state 
language  consists  of  Li  with  all  occurrences  of°  replaced  by  ?  (as  in  Definition  4-6),  and 
extended  with  the  following  term  constructors: 

r  b  M  :  {a  — >■  *0)  — >■  *0  V  h  M  :  a 

r  b  C  M  :  'a  r  h  !  st  :  V  T  h  st  :=  M  :  T 

Note  that,  the  type  a  can  be  a  complex  type,  such  as  /.—>■*<,,  so  that  values  stored  in  the 
cell  can  be  procedures  that  themselves  read  or  modify  the  state.  This  again  introduces 
a  reflexivity  in  the  types,  and  it.  is  well  known  that  one  can  define  a  fixed-point  operator 
using  higher-order  state  (as  actually  done  for  letrec  in  Scheme  [CR91]).  As  usual,  we 
give  a  definitional  translation  of  the  new  language: 

Definition  4.24  Let  9  be  a  computation-type  of  V(,  and  let  a  be  a  L\-type.  Then  the 
translation  |-]s  from  Lcls,t  to  Lf  is  given  by,  on  types: 

P«Is  =  where  °  =  /ia- 

We  have  <fs  :  [<j]s  -A*  a  and  #  :  a  M  [<j]s  in  the  two  directions.  (As  usual,  these  can 
be  taken  as  identities  if  a  does  not  contain  f.)  Then  we  can  give  the  term  translations  of 
the  new  constructs: 


[  ’M\, 

[let1’  x  ■$=  Mi  in  M2]s 

[CM]. 

i!st]s 

[st  :=  M]s 


Xk.  As.  k  [M]s  s 

X k.  As.  [Mjg  (Xx.  As7.  [M2js  k  s')  s 

Xk.Xs.  [M]s  ( Xa.Xq.Xs'.kas ')  (Xz. Xs" .V z s") s 

Xk.  As.  k  (fis  s)  s 

Xk.Xs.  k(){<nM]s) 


Again,  all  but  the  underlined  instances  of  state-passing  in  the  above  can  be  eta- 
reduced  away.  In  other  words,  for  the  core  computational  structure,  this  is  a  standard 
continuation-translation  with  answer  type  a  — >■  9. 


Now  pick  a  =  u  — >■  T0.  We  then  have 

a  =  {uj  -)•  f0]s  =  [ lo]s  -)•  (0  ~^a^9)^a^9 

We  will  use  a  to  represent  our  metacontinuation  7.  Although  this  state-based  encod¬ 
ing  of  7  now  also  gets  passed  a.  continuation  0  — >■  and  a.  state  <7,  it  will  use  neither  of 

these.  That  is,  we  informally  have  “d  =  [cj]s  — )■  0”. 
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Having  chosen  a  suitable  state  type,  we  also  need  to  express  the  relevant  operations 
on  the  metacontinuation  in  terms  of  the  constructs  of  our  continuation-state  language. 
For  conciseness,  we  introduce  the  abbreviation: 

F  b  :  A  r  b  M2:Ta 
r  M::M.;:Tn 


with  expansion 

My;  M2  =  letf  ()  4=  Mi  in  M, 

We  already  have  value-inclusion,  computation-sequencing,  and  escapes  directly  avail¬ 
able  in  LcLScr .  For  the  remaining  two  constructs  of  //  (  .  we  take: 

Definition  4.25  Let  d  be  an  L\-type.  Then  in  if"  we  define  operators  A  and  fi, 
typed  as  in  Definition  f.6,  as  follows: 

AM  A  letf  g  <=  1st  in  gM 

#M  =  C  (A let*  (/<(=!  st  in  (st  :=  (Aw“.  (st  :=  g\  cv));  let*  x  -<=  M  in  Ax)) 

Note  in  particular  that  the  procedure  stored  into  st  in  ff  does  not  use  the  previous 
value  of  st,  nor  does  it  return  to  its  point  of  call  (not  that  it  could,  since  its  return  type 
is  empty). 

We  now  set  up  a  system  of  logical  relations  suitable  for  showing  that  the  above  state- 
based  definitions  of  the  control  operators  capture  the  behavior  of  the  metacontinuation- 
based  translation: 

Lemma  4.26  Let  there  be  given  a  relational  correspondence  between  two  interpretations 
C  and  C  of  Lf,  with  a  computation- extension  of  relations  R  i— >■  °R.  Let  ~  G  CARel  (0,6) 
be  an  arbitrary  computation- admissible  relation  on  ultimate  answers.  Then  there  exists 
a  collection  of  relations  with  the  following  properties: 

•  On  “ wrapped ”  ultimate  answers:  G  CARel (9,  (0  — >■  -id)  — >■  d  — >■  6) 

m  m  -<=>  \/q  G  VaR/ (0  — >■  -id),  s  G  VaR/(d).  m  ~  m  qs 

•  On  7netacontin.uati.ons/state:  x  G  ARelR,d), 

jxs  -<=>  g  )►  ~*)  ffs  -<=>  Vr  r' .  fp  gr  sr' 

•  On  meta-computations:  G  CARel — >■  9,  d  — >■  6)  =  (x  — >■  ~),  i.e., 

x  xx  x  -<=>  \/g  x  s.  x  g  ~  x' s 

•  On  values:  for  any  L\-type  a,  ~ a  G  ARel([o:]A.n ,  [n]s ),  defined  in  the  usual  way 
for  the  standard  type  constructors,  and  in  particular, 


u  ~tQ  u  -<=>  u  ((~a  —>■?«)—)■?«)  u 
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Proof.  First  assume  that  the  relation  x  is  given  independently,  and  define  the  oth¬ 
ers  in  terms  of  it  (thus  satisfying  all  of  the  equivalences  in  the  lemma  except  the  one 
characterizing  x).  Further,  define  *x  G  CARel([cj]Kn  —>  9,  [x]5  — >■  (0  — >■  -id)  — >■  d  — >■  6)  by 

7  (*x)  A  <7=>  7  (~tlJ  — >■  ~*)  7'  Vr  rh  7 r  7 ' r' 

is  a  computation-admissible  relation,  being  given  as  an  intersection  over  inverse 
images  of  ~  by  the  (rigid)  functions  id  on  the  LHS  and  A m.mqs  on  the  RHS.  (~*  does 
not  depend  on  x,  so  there  is  no  concern  about  admissibility  of  the  action  defining  it.) 
All  of  the  relational  actions  defining  *x  from  x  are  thus  standard,  so  by  Theorem  4.11 
we  can  take  x  as  the  invariant  relation  for  the  overall  action,  i.e. , 

9  x  Ca9  (*x)  Uss 

giving  us  the  remaining  equivalence  of  the  lemma.  ■ 

Having  established  existence  of  the  appropriate  relations,  we  can  now  easily  show 
correctness  of  the  state-based  representation  of  the  metacontinuation: 

Lemma  4.27  Let  F  F  M  :  a  be  a  term  of  if  (  and  a  >~^r  a'.  Then  [M]^.n  [M]^ 

(where  on  the  RHS  we  use  the  expansions  of  A  and  ff  froin  Definition  f.25. 

Proof.  By  induction  on  M.  Most  cases  are  immediate,  with  the  term  constructors 
having  the  same  expansions  in  the  two  translations.  The  only  exceptions  are: 

•  Case  AM.  We  first  compute 

IAM}S  =  [letT  g  <=  1st  in  gMjs  =  A<j.  As.  [!  st]s  {Xg.Xs1  .{g  MJS  qs')  s 
=  Xq.Xs.{Xg.Xs'.glM}sqs'){ifss)s  =  Xq.Xs.{f)s s){Mjs  qs 

We  must  then  show  that  [AlM]^n  [4M]^  ,  i.e.,  that 

Xq.Xg.(Uag){M]Kn  ~.0  Xq.  As.  ($*s)  [MfJ  q' s 

So  let  <7  (0  — ^  ~)  r/'.  Then  we  must  show 

Xg.(r9)lMTKn  «AS.(^S)[M]£V* 

Accordingly,  let  g  x  s;  it  then  suffices  to  show  that 

(rg)maKn  ^ 

which  follows  from  the  definition  of  g  x  s  and  the  IH  that  [M]^.n  [M]^ . 

•  Case  ffM.  Again,  we  first  expand  the  RHS: 

[#M]S  =  [C  (Ac, let’  g  x=  !  st  in  (st  :=  (A«.  (st  :=  g-r  cv));  letT  x  ^  M  in  As))]s 
=  •  •  •  =  A  k.  As.  [M]s  (Aa;.  Ash  (ipa  s')x(Xz.V  z)  sr)  (( pa  ( Xv .  Xq.  A  s" .  kv(fs  ('fs  s)))) 

=  A k.  As.  [M]s  (Aa:.  Ash  (ips  s)x{Xz.V z) s)  {tjf  {Xv.  Xq.  As” .  kvs)) 

[#M]f ,  i.e.,  that 


We  must  now  show  that  [#M]C 
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A  k .  Xg .  [M]  A,n  ( Ar .  Xg’ .  g'  r )  ( 0n  ( Xa .  k  ag) ) 

A  A:7.  As.  \M\as  (Ad.  X s' .  ('0s s')x  (A z.V z)  s7)  (0s  (Ad.  A q.  X s" .  k!  vs)) 

As  usual,  assume  k  (~u  —>  ?a)  A:7  and  g  x  s;  we  must  then  show 

lMfK n  (Ar.  Xg'.fjR g  r)  (0n  (Xa.kag)) 

~  [M]^  (Ad.  As7.  ('0ss7)d  (A^:.  V 2)  s7)  (0s  (Ad.  Ag.  As77.  A:7  d  s)) 

By  IH  on  M,  it  suffices  to  show  that  the  continuations  and  metacontinuations 
passed  to  the  two  translations  are  related.  For  the  continuations,  we  must  show 
that  if  r  x  and  g'  x  s'  then 

,0n  g'  v  ~  ('iff  s')  x  (Xz.  V z)  s' 

which  follows  from  the  definition  of  g'  x  s' .  Similarly,  for  the  metacontinuations, 
we  must  show  that 

0n  (Xa.kag)  x  (ff  (Xv.  Xq.  Xs" .  k'  v  s) 

Again,  by  definition  of  x,  this  requires  showing  that  for  r  r' . 

'0n  (0n  (Xa.  kag))r  #  (0s  (Ad.  Xq.  Xs" .  k'vs))r' 
i.e. ,  cancelling  the  isomorphisms,  that 

k  r  g  — *  Xq.  Xs" .  k'  r' s 

which  follows  immediately  from  the  definition  of  and  the  assumption  on  k  and 
k'. 


4.4  Putting  it  all  together 

Summarizing  the  results  of  this  chapter,  we  can  state: 

Theorem  4.28  Let  there  be  given  a  relational  correspondence  between  a  language  ( L^ ,  C) 
and  itself,  with  a  computation- extension  of  relations  R  1— ?•  °R  such  that  ~  =  °(/r)  is  an 
equivalence  relation. 

Further,  let  [-]c,  :  be  the  translation  of  ambient  effects  using  the  continuation 

monad  with  answer  type  6  =  °/  from  Definition  f.lf,  p  G  Val £0  — ?-0)  a  printing  function, 
and  ao  G  Val c(Q)  an  error  answer. 

Finally,  letu  be  a  type  of  L\,  [-]A.  the  continuation-passing  transform  with  answer  type 
lo  from  Definition  3.3 f,  and  [-]s  the  continuation-state  transform  from  Definition  f.2f, 
with  state  type  o  =  |cj|  — )■  T0  and  ultimate- answer  type  6. 

Then  for  any  complete  program  •  b  M  :  °t  in  Lf , 

IWhclcP  -  lMi}s  ( Xn.Xs'.pn )  (0s  (Ad.  Ag.  As. do)) 

where  •  h  M[  :  Tt  is  a  term  of  LcvSa  obtained  syntactically  from  M  by  (1)  erasing  all 
level-annotations  on  value-inclusions  and  lets,  and  (2)  defining  gK(~)  and  [-]K  in  terms 
of  escapes  and  state  as  detailed  in  Lemmas  f.3  and  f.f,  and  Definition  f.25. 
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(For  a  correctly  effect-stratified  program  M,  the  initial  error-metacontinuation  on  the 
right-hand  side  will  never  be  invoked.  When  the  implementation  is  hosted  in  an  ML-like 
language,  however,  the  system  cannot  statically  verify  that  M  is  typable  in  our  stricter 
system,  only  that  the  level-erasure  of  M  is  ML-tvpable.  Pragmatically,  to  give  a  more 
useful  behavior  for  effect-typing  errors  (notably  if  M  has  escaping  control-effects,  i.e. ,  if 
it  effectively  has  type  '/  rather  than  °/.),  we  therefore  take  the  initial  metacontinuation  to 
produce  a  distinct  answer  a0  when  invoked;  we  want  to  show  that  the  simulation  is  still 
correct  with  this  error-catching  extension.) 

Proof.  First,  let  Cc  be  the  predomain  semantics  for  the  ambient-effect  monad  induced 
by  K  ,  (which  is  easily  checked  to  be  a  uniform  monad  in  the  predomain  semantics)  as 
in  Proposition  2.20.  Proposition  2.25  (straightforwardly  extended  to  the  additional  term 
constructors  of  L'( )  then  gives  us  that 


Cc[~]  -  £[[-L] 

for  types  and  terms.  Moreover,  the  standard  relational  action  of  K%  in  C.  i.e., 

rn  ( CR )  rn  <yy>  m  ((R—>  °t)  —>  T)  rn 

< '==>  Vy,  y7.  (Va  R  a.  y  a  ~  y  'a')  =>■  m  y  ~  rn  y 

is  easily  seen  to  be  a  computation-extension  for  the  notion  of  ambient  effects  determined 
by  the  continuation  monad:  for  any  a  and  a'  such  that  a  R  a 

[a]c  =  Xk.ka  ((R^  ~)->  ~)  Xk.ka'  =  [V]c, , 


and  similarly  for  let°. 

Let  AT  now  be  the  -program  obtained  from  M  by  defining  /jk(~)  and  [-]K  in 
terms  of  C ,  A.  and  #  (still  with  their  two-level  types).  Then  from  Definition  4.5  (with 
associated  lemmas)  we  get  that  in  Cc.  [M]A.  =  [M7]A,  and  hence  in  C  that 

[M,.-]cP  =  [IM'LLp  C) 

We  can  now  use  the  level-erasure  Lemma  4.13  to  get,  in  the  relational  correspondence 
between  the  two  copies  of  Cc- 

[Af']„  [|M'|]r 

Since  >-£  is  simply  equality  of  numerals,  this  expands  to 

Veto  type^/' ,  O  G  ARel£Cj£c(o:o,£j),  k  £  Val £c(a — ?■  cto )-kl  £  Val£c(t — )•  uj). 

(Vn  £  N.  kn  (°0)  k'n)  =y  let°  x  <=  [M'jK  in  kx  (°0)  l\M'\jgk' 

Or,  in  the  original  correspondence: 


Vtt0  typeLM,  O  £  ARelA£([a0]c,  Hc)i 

k  £  \  al£(/  — >  ([etoJc  — t  9)  — >  6),k '  £  \  al£(/.  — >  ([cj]c,  — >  9)  — >  9). 

(Vn  £  N.  kn  (CO)  k'n )  =y  Ay.  [[M']K]0  (Ax.  kx y)  (CO)  [[|M7|]iT]c,  k' 


Somewhat  surprisingly,  the  actual  choice  of  the  relation  O  does  not  matter  much;  it  is 
the  use  of  C  to  computation-extend  O  that  is  important.  In  fact,  we  can  simply  take 
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a0  =  0,  and  O  to  vacuously  relate  every  element  of  0  to  every  element  of  [cj]c.  Then 
consider  the  two  continuations 

k  =  An1 .  Ay°^# .pn  and  k'  =  Xnh .  Xn/'Mc^8  .pn  . 

Let  n  be  a  natural  number;  we  must  show  that  kn  (CO)  k' n,  i.e. ,  that 

Vy,  y7.  (Vo  O  o' .  y o  ~  y 'o')  =y>  A;ny  ~  k' ny7 . 

Since  both  k  and  k'  ignore  their  metacontinuation  arguments,  this  reduces  to  pn  ~  pn, 
which  we  get  from  reflexivity  of  ~.  We  thus  have: 

'W-  HM'Uc  P  =  ^7-  HIT'LL  (^-  kxl) 

(CO)  ll\M'\}jf}ck'  =  Ay7.[[|M7|]^]c,  (An.  Ay". pm) y7 

Take  y  =  A^.V^z  and  y7  =  Ao.ao;  they  vacuously  map  all  0-related  values  to  ~- 
related  results.  Expanding  the  definition  of  CO,  we  therefore  get: 

IWhlcP  -  ilA/,|L-]o  (An. Ay'.pn)  (Ao.a0)  (*) 


We  can  now  take  the  step  to  escapes  and  state.  Let  Mi  =  \M'\.  First,  Lemma  4.16 
gives  us 

(An.  Ay  ".pn)  (Xx.  a0)  =  (An.  Ay "  .pn)  (Xx.  a0)  (*) 

and  then  Corollary  4.22, 

[Mi]|u  (An.  Xj" .pn)  (X x.a0)  =  [Mi]A,n  ( Xn.Xg.pn )  ((jT(Xx.a0))  (*) 

From  Lemma  4.27,  we  get,  in  the  ^-correspondence: 

[A/,],,..  [m;]s 

where  M\  is  obtained  from  M\  by  defining  A  and  #  in  terms  of  C,  !  st  and  st  :=  -  as  in 
Definition  4.25.  We  want  to  get  from  this  that 

[Mi]A.n  (Xx.  Xg' .px)  (<j)n  (Xx.a0))  ~  [M(]s  (Xx.  Xs'.px)  (<jf  (Xx.  Xq.  As.  a0))  (*) 

Expanding  the  definition  of  we  need  to  verify  that  the  continuations  are  related, 
i.e.,  that  for  every  n  n!  (i.e.,  n  =  n'),  Xg' .pn  &  Xs'.pn! ,  which  again  reduces  to  just 
pn  ~  pn' .  We  must  also  check  that  the  initial  metacontinuation  and  state  are  related  by 
x,  i.e.,  that  for  r  r' ,  and  q,  s  arbitrary, 

V,n  (r t>n  (Xx.  a0))r  ~  (i/js  (c i>s  (Xx.  Xq.  As.  a0)))r'  qs 

And  that  is  true  since  both  sides  simplify  to  a0. 

Finally,  taking  the  lines  marked  with  (*)  above  together  in  sequence,  using  the  trans¬ 
itivity  of  ~,  gives  us  the  desired  result.  ■ 
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And  finally,  taking  this  theorem  together  with  Chapter  3,  with  nontermination  as  the 
notion  of  ambient  effects,  and  simply  diverging  for  effect-typing  errors,  we  get: 


Corollary  4.29  Let  £_l  be  the  partiality  interpretation  of  L^,  and  let  T  be  a  rnonad  in 
(Lq,C±).  Then  we  can  pick  a  state  type  a  in  L\  such  that  for  any  complete  -program 
•  h  M  :  °t, 

£l[[M]t](«)  =  (An.  As'  An)  (cf  (\x.  £))](•) 

where  M'  is  a  term  of  LC{S°  obtained  syntactically  from  M  by  (1)  erasing  all  the  levels 
on  value-inclusions  and  lets,  and  (2)  defining  /iT(-)  and  [-]T  in  terms  of  escapes,  state, 
embeddings,  and  the  term  constructors  of  T. 

Proof.  In  the  partiality  semantics,  with  relation  lifting  as  the  computation-extension, 
two  closed  terms  of  type  °l  are  related  by  ~  =  °(/r)  iff  their  denotations  are  equal  in  the 
model  (so  in  particular,  ~  is  an  equivalence  relation). 

First,  let  T0  =  I  be  the  identity  monad  (Example  2.16)  and  U0  =  K-,  the  continuation 
monad  with  answer  type  °z.  (Definition  3.4).  Then  by  Lemma  3.5  there  is  a  monad 
morphism  h  from  T0  to  U0  defined  as  follows: 

hQ  =  Am  Ay'*-" '.  let°  a  <=  m  in  ya 

From  this,  Proposition  3.27  gives  us  a  monad  relation  between  I  and  K  , .  mapping  a 
relation  R  G  ARel(a,  a')  to  ‘R  G  CARelfA,  (a  — >■  °l)  — >■  °i)  by: 

m  ('R)  m  h  m  =  Ay.  let °  x  <=  m  in  y.r  ((R  — )■  ~)— )■  ~)  m 

Vy,  y7.  (Va  R  a’ .  y a  ~  y 'a')  =>■  let°  x  •<=  m  in  'yx  ~  m! y-/ 

Hence,  by  Proposition  3.40,  we  get  a  relational  correspondence  between  the  interpreta¬ 
tions  given  by  £s[-]  =  £±[-]  and  £;[-]  =  £j_[[-]c,],  with  computation-extension  °R  taken 
as  the  'R  defined  above. 

Theorem  3.38,  with  N  taken  as  an  enumeration  of  all  closed  L^-types,  now  gives  us 
that,  in  the  correspondence  between  Cs  and  £;, 

mT  (vj  [Mil,.- 

where  Af  in  is  obtained  from  M  by  defining  //'(-)  and  [-]T  in  terms  of  and 

[-]K,  the  components  of  T,  and  the  operations  for  embedding-types.  Using  //'  as  our  R 
above,  with  y  =  y7  =  Xx.°x,  we  thus  get  in  the  original  correspondence: 

[M]t  =  let°  x  -<=  \M\t  in  ( \x.°x)x  ~  ( \x.°x ) 

And  from  this,  we  get  the  desired  result  directly  by  Theorem  4.28  with  p  =  \x.°x  and 
a  o  =  -Lv  ■ 
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4.5  ML  implementation  and  examples 

In  this  section  we  illustrate  how  the  abstract  construction  presented  so  far  can  be  tran¬ 
scribed  into  runnable  code.  To  emphasize  the  typing  issues  involved,  we  use  the  New 
Jersey  dialect  of  Standard  ML  [AM91]  as  our  concrete  language,  but  the  operational 
content  should  translate  straightforwardly  into  Scheme  as  well  (though  instantiation  to 
different  monads  may  be  less  convenient  without  a  “parameterized  module”  facility). 
We  also  give  several  examples;  the  reader  may  want  to  compare  these  with  Wadler’s 
presentation  [Wad92b], 

4.5.1  Composable  continuations 

In  SML/NJ,  first-class  continuations  have  a  type  distinct  from  the  type  of  general  pro¬ 
cedures.  Let  us  therefore  first  set  up  a  Scheme-style  representation  of  such  continuations 
as  non-returning  procedures  (this  is  not  essential  but  makes  for  a  more  direct  corres¬ 
pondence  with  the  development  in  Section  4.3): 

signature  ESCAPE  = 
sig 

type  void 

val  coerce  :  void  ->  ’a 

val  escape  :  ((’la  ->  void)  ->  void)  ->  ’la 

end; 

structure  Escape  :  ESCAPE  = 
struct 

datatype  void  =  VOID  of  void 
fun  coerce  (VOID  v)  =  coerce  v 

fun  escape  f  =  callcc  (fn  k  =>  coerce  (f  (fn  x  =>  throw  k  x))) 

end; 

For  example,  we  can  write 

let  open  Escape 

in  3  +  escape  (fn  k  =>  k  (6  +  coerce  (k  1)))  end; 

(*  val  it  =  4  :  in t  *) 


(The  use  of  void  and  coerce  instead  of  an  unconstrained  type  variable  in  Escape  permits 
continuations  to  be  stored  in  ref-cells  while  staying  within  the  ML  type  system  [HDM93].) 

Now  we  can  define  a  composable-continuations  facility,  parameterized  by  the  type  of 
final  answers  (using  Definition  4.25  and  Lemma  4.4): 

signature  CONTROL  = 
sig 

type  ans 

val  reset  :  (unit  ->  ans)  ->  ans 

val  shift  :  ((’la  ->  ans)  ->  ans)  ->  ’la 

end; 

functor  Control  (type  ans)  :  CONTROL  = 

struct 
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open  Escape 

exception  MissingReset 

val  ink  :  (ans  ->  void)  ref  =  ref  (fn  _  =>  raise  MissingReset) 
fun  abort  x  =  (!mk  x) 

type  ans  =  ans 
fun  reset  t  = 

escape  (fn  k  =>  let  val  m  =  !mk 

in  mk  :=  (fn  r  =>  (mk  :=  m;  k  r)); 
abort  (t())  end) 

fun  shift  h  = 

escape  (fn  k  =>  abort  (h  (fn  v  =>  reset  (fn  ()=>coerce  (k  v))))) 

end; 


For  example, 

structure  IntCtrl  =  Control  (type  ans  =  int) ; 
let  open  IntCtrl 

in  1  +  reset  (fn  ()  =>  2  *  shift  (fn  k  =>  k  (k  10)))  end; 
(*  val  it  =  41  :  int  *) 


4.5.2  Monadic  reflection 

Building  on  the  composable-continuations  package,  we  implement  the  construction  of 
Section  3.3.5.  The  signature  of  a  monad  is  simple: 


signature  MONAD  = 
sig 

type  ’ a  t 

val  unit  :  ’a  ->  ’at 

val  ext  :  (’a  ->  ’b  t)  ->  ’a  t  ->  ’b  t 

val  show  :  string  t  ->  string 

end; 


(The  monad  laws  have  to  be  verified  manually,  though.)  The  component  show  is  included 
in  the  signature  for  convenience  only.  We  require  it  to  satisfy  show  o  unit  =  id ;  on  terms 
that  do  not  factor  through  unit,  it  provides  an  informal  string-based  representation  of 
the  effect  if  possible.  It  might  at  first  seem  more  general  to  parameterize  over  types, 
i.e. ,  have  a  show’:  (’a  ->  string)  ->  ’a  t  ->  string,  but  we  can  recover  that  as 
fn  ms=>fn  t=>show  (ext  (unit  o  ms)  t).  Our  goal  is  to  define  reflection  and  reific¬ 
ation  operations  for  an  arbitrary  monad  M  to  get 


signature  RMONAD  = 
sig 

structure  M  :  MONAD 

val  reflect  :  ’la  M.t  ->  ’la 

val  reify  :  (unit  ->  ’la)  ->  ’la  M.t 

val  run  :  (unit  ->  string)  ->  string 

end; 
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Here,  run  is  again  mostly  for  illustration  purposes:  it  takes  a  suspended  string-returning 
computation  and  returns  the  result  of  executing  it,  annotated  by  an  external  represent¬ 
ation  of  its  computational  effects,  if  any. 

Using  Control  we  can  now  define  a  representation  of  the  continuation  monad  for  an 
arbitrary  answer  type  (Lemma  4.3,  but  simplified  because  of  level-erasure): 

functor  ContMonad  (type  answer)  :  MONAD  = 

struct 

type  ’a  t  =  (’a  ->  answer)  ->  answer 
fun  unit  a  =  fn  k  =>  k  a 
fun  ext  f  t  =  fn  k  =>  t  (fn  a  =>  f  a  k) 
fun  show  t  =  raise  Fail  "show  not  defined" 

end; 

functor  ContRep  (type  answer)  :  RMONAD  = 

struct 

structure  C  =  Control  (type  ans  =  answer) 

structure  M  =  ContMonad  (type  answer  =  answer) 
val  reflect  =  C. shift 

fun  reify  t  =  fn  k  =>  C. reset  (fn  ()  =>  k  (t  ())) 
fun  run  t  =  raise  Fail  "run  not  defined" 

end; 

(where  show  and  run  cannot  be  defined  when  the  answer  type  is  unknown). 

To  implement  the  general  construction,  we  also  need  to  somehow  represent  the  in- 
finitary  embedding  type  from  Section  3.3.4.  This  might  at  first  seem  fundamentally 
incompatible  with  SML’s  type  system,  especially  if  we  want  a  “parametric”  solution, 
independent  of  the  collection  of  available  base  types  and  type  constructors.  But  the  con¬ 
struction  only  requires  us  to  exhibit  an  embedding  for  those  types  at  which  we  actually 
perform  a  reification.  Thus,  all  we  need  is  what  could  be  called  a  “generative  type 
dynamic”:  a  structure  matching 

signature  DYNAMIC  = 

sig 

type  dyn 

val  newdyn  :  emit  ->  ( ’  la  ->  dyn)  *  (dyn  ->  ’ la) 

end; 

such  that  for  any  monotype  ’  la,  an  invocation  of  newdyn  ()  returns  a  pair  of  functions 
(to_d,  from_d)  with  from_d  o  to_d  equal  to  the  identity  on  ’la.  This  signature  can 
actually  be  implemented  type-safely  in  SML,  by  exploiting  the  fact  that  the  standard 
datatype  exn  (nominally  of  exception  names ,  but  useful  for  other  purposes  as  well)  can 
be  dynamically  extended  with  new  summands: 

structure  Dynamic  :  DYNAMIC  = 

struct 

exception  Dynamic 
abstype  dyn  =  DYN  of  exn 
with  fun  newdyn  ()  = 

let  exception  E  of  ’la 

in  (fn  a  =>  DYN  (E  a) ,  fn  DYN  (E  a)  =>  a  |  =>  raise  Dynamic)  end 
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end 

end; 

Note  that  we  never  actually  raise  or  handle  the  exception  E  anywhere;  we  only  use  it  as 
a  dynamically-allocated  tag. 

Remark  4.30  Encoding  dynamic  types  in  terms  of  exception  names  is  probably  the 
most  efficient  approach  in  SML/NJ  (short  of  bypassing  the  type  system  entirely  via 
System. Unsaf  e .  cast),  but  we  do  not  actually  depend  on  existence  of  an  “extensible 
datatype”  for  the  construction.  In  fact,  we  can  get  the  same  effect  by  representing  a 
value  of  type  dyn  as  a  procedure  unit  ->  unit,  setting  a  specific  cell  to  the  desired 
value: 

structure  Dynamic’  :  DYNAMIC  = 

struct 

exception  Dynamic 
abstype  dyn  =  DYN  of  unit  ->  unit 
with  fun  newdyn  ()  = 
let  val  r  =  ref  NONE 

in  (fn  a  =>  DYN  (fn  ()  =>  r  :=  SOME  a), 
fn  (DYN  d)  => 

(r  :=  NONE;  d  () ; 

case  !r  of  SOME  a  =>  a  |  NONE  =>  raise  Dynamic))  end 

end 

end; 

However,  this  needlessly  builds  a  closure  for  the  dynamic  value,  and  is  perhaps  a  bit  more 
obscure  than  the  exn-based  definition  above.  ■ 


We  can  now  complete  the  construction  (Theorem  3.38): 

functor  Represent  (structure  M  :  MONAD)  :  RMONAD  = 

struct 

structure  CR  =  ContRep  (type  answer  =  Dynamic. dyn  M.t) 

structure  M  =  M 

fun  reflect  m  =  CR. reflect  (fn  k  =>  M.ext  k  m) 
fun  reify  t  = 

let  val  (to_d,  from_d)  =  Dynamic .newdyn  () 
in  M.ext  (M.unit  o  from_d)  (CR. reify  t  (M.unit  o  to_d))  end 
fun  run  t  =  M.show  (reify  t) 

end; 

4.5.3  Example:  exceptions 

Example  1.5  from  the  Introduction  becomes,  in  the  concrete  setting  of  our  ML-based 
implementation: 

structure  ErrorMonad  = 
struct 

datatype  ’a  t  =  SUC  of  ’a  |  ERR  of  string 
val  unit  =  SUC 
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fun  ext  f  (SUC  a)  =  f  a 
I  ext  f  (ERR  s)  =  (ERR  s) 
fun  show  (SUC  a)  =  a 

I  show  (ERR  s)  =  "<Error:  "  ~  s  ~  ">" 

end; 

functor  ErrorOps  (structure  R  :  RMONAD  sharing  R.M  =  ErrorMonad)  : 
sig 

val  myraise  :  string  ->  ’la 

val  myhandle  :  (unit  ->  ’2a)  ->  (string  ->  ’2a)  ->  ’2a 

end  = 
struct 

open  ErrorMonad 

fun  myraise  e  =  R. reflect  (ERR  e) 

fun  myhandle  t  h  =  case  R. reify  t  of  SUC  a  =>  a  |  ERR  s  =>  h  s 

end; 

Note  that  the  operations  myhandle  and  myraise  are  defined  generically  in  terms 
of  any  valid  implementation  of  reflection  and  reification  for  the  exception  monad.  For 
example,  since  SML  already  has  exceptions  we  could  simply  take 

structure  ErrorRep’  :  RMONAD  = 

struct 

exception  Exc  of  string; 

structure  M  =  ErrorMonad  open  M 
fun  reflect  (SUC  a)  =  a 

I  reflect  (ERR  e)  =  raise  Exc  e 
fun  reify  t  =  SUC  (t  ())  handle  Exc  e  =>  ERR  e 
fun  run  t  =  show  (reify  t) 
end; 

We  can,  however,  also  plug  in  the  “canonical”  definitions  obtained  from  Represent: 

structure  ErrorRep  =  Represent  (structure  M  =  ErrorMonad) 
structure  FX  =  ErrorOps  (structure  R  =  ErrorRep)  open  FX; 

fun  mydiv  (x,y)  =  if  y  =  0  then  myraise  "DivO"  else  x  div  y; 

(*  val  mydiv  :  in t  *  int  ->  int  *) 

ErrorRep. run  (fn  ()  =>  makestring  (1  +  mydiv  (100,  3))); 

(*  val  it  =  "34"  :  string  *) 

ErrorRep. run  (fn  ()  =>  makestring  (1  +  mydiv  (100,  0))); 

(*  val  it  =  "<Error:  Div0>"  *) 

ErrorRep. run  (fn  ()  =>  myhandle  (fn  ()  =>  makestring  (1  +  mydiv  (100,  0))) 

(fn  s  =>  "Oops:  "  ~  s)); 

(*  val  it  =  "Oops:  DivO"  *) 

The  type  inferred  for  myraise  above  is  actually  overly  conservative  wrt.  weakness: 
since  an  exception-raising  operation  never  returns  normally  in  the  first  place,  it  is  safe 
to  give  it  a  fully  polymorphic  type.  We  can  achieve  this  by  simply  changing  the  defin¬ 
ition  of  myraise  to  Escape .  coerce  (reflect  (ERR  e)).  Unfortunately,  myhandle  is 
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also  only  weakly  polymorphic,  which  can  be  traced  back  to  the  fact  that  reify  in  the 
functor  Represent  has  a  weakly  polymorphic  type  (and  that  itself  is  a  consequence  of 
its  definition  in  terms  of  Dynamic  .newdyn). 

It  is  instructive  to  inspect  the  expansion  of  myraise  and  myhandle  into  the  underlying 
state  and  continuation  manipulations:  the  cell  allocated  for  the  metacontinuation  in 
Control  effectively  contains  the  “current  handler  continuation”,  which  is  invoked  by  a 
raise  and  temporarily  rebound  in  the  scope  of  each  new  handle.  This  is  very  much  like 
the  way  exceptions  are  actually  implemented  in  SML/NJ,  although  the  details  are  not 
quite  the  same:  an  exception-specific  implementation  can  take  advantage  of  particular 
operational  properties  of  the  monad  (notably  that  handler  continuations  are  invoked  at 
most  once)  to  optimize  the  generic  construction  a  bit. 


4.5.4  Example:  state 

The  state  monad  is  straightforward: 


functor  StateMonad  (type  state)  :  MONAD  = 

struct 

type  ’a  t  =  state  ->  ’a  *  state 
fun  unit  a  =  fn  s  =>  (a,s) 

fun  ext  f  t  =  fn  s  =>  let  val  (a, s’)  =  t  s  in  f  a  s’  end 
fun  show  t  =  raise  Fail  "not  defined" 

end; 

structure  IntStateMonad  :  MONAD  = 

struct 

structure  S  =  StateMonad  (type  state  =  int)  open  S 
fun  show  t  = 

let  val  (a, s’)  =  t  42 

in  if  s’  =42  then  a  else  "<s:  "  ~  makestring  s’  ~  ">  "  "a  end 

end 


functor  IntStateOps  (structure  R  :  RMONAD  sharing  R.M  =  IntStateMonad)  : 

sig 

val  store  :  int  ->  unit 
val  fetch  :  unit  ->  int 
val  tick  :  unit  ->  unit 

end  = 
struct 

fun  store  n  =  R. reflect  (fn  s  =>  (0,n)) 
fun  fetch  ()  =  R. reflect  (fn  s  =>  (s,s)) 
fun  tick  ()  =  R. reflect  (fn  s  =>  ((),s+l)) 

end 


structure  IntStateRep  =  Represent  (structure  M  =  IntStateMonad) 
structure  FX  =  IntStateOps  (structure  R  =  IntStateRep)  open  FX; 


IntStateRep. run  (fn  ()  =>  (store  5;  tick  () ; 

let  val  x  =  fetch  () 

in  tick  ();  makestring  (2  *  x)  end)); 

(*  val  it  =  "<s:  7>  12"  *) 
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Here  the  general  construction  is  clearly  wasteful,  however:  we  could  easily  have  rep¬ 
resented  the  state  monad  without  using  callcc  at  all.  This  is  also  true  for  many  other 
“state-like”  monads,  such  as  I/O  or  complexity.  Thus,  the  real  value  of  the  general  con¬ 
struction  is  when  the  decomposition  into  escapes  and  state  is  not  immediately  apparent, 
as  in  the  following  examples. 

4.5.5  Example:  nondeterminism 

A  nondeterministic  computation  can  be  represented  as  a  list  of  answers.  (Formally,  this 
goes  beyond  the  monads  considered  in  Chapter  3,  but  extending  the  proof  to  a  language 
with  inductive  datatypes  such  as  lists  is  straightforward.) 

structure  ListMonad  :  MONAD  = 

struct 

type  ’at  =  ’a  list 
fun  unit  a  =  [a] 
fun  ext  f  []  =  [] 

I  ext  f  (h::t)  =  f  h  I  ext  f  t 
fun  show  []  =  "<fail>" 

I  show  [x]  =  x 

I  show  (h: :t)  =  h  ~  "  <or>  "  ~  show  t 

end; 

functor  ListOps  (structure  R  :  RMONAD  sharing  R.M  =  ListMonad)  : 
sig 

val  pick  :  ’la  list  ->  ’la 

val  fail  :  unit  ->  ’la 

val  results  :  (emit  ->  ’la)  ->  ’la  list 

end  = 
struct 

fun  pick  1  =  R. reflect  1 
fun  fail  ()  =  R. reflect  [] 
fun  results  t  =  R. reify  t 

end; 

structure  ListRep  =  Represent  (structure  M  =  ListMonad) 
structure  FX  =  ListOps  (structure  R  =  ListRep)  open  FX; 

ListRep. run  (fn  ()  =>  let  val  x  =  pick  [3,4]  *  pick  [5,7] 

in  if  x  >=  20  then  makestring  x  else  fail  ()  end) ; 

(*  val  it  =  "21  <or>  20  <or>  28"  :  string  *) 

More  generally,  we  get  Haskell-stvle  list  comprehensions  “for  free” ,  in  that  the  schema 

[E  |  x\  <—  Eii  ■  ■  •  j  xn  <  En\ 

(where  each  x.i  may  be  used  in  Ej,+ 1, . . . ,  En  and  in  E)  can  be  expressed  directly  as 

[let  xi  =  n(Ei)  in  . . .  let  xn  =  fi(En )  in  E~\ 

Of  course,  this  is  probably  not  the  most  efficient  way  of  implementing  list  comprehen¬ 
sions  in  ML.  As  observed  by  Wadler,  however,  list  comprehensions  can  be  generalized 
to  arbitrary  monads  [Wad92a];  similarly  we  get  general  monad  comprehensions  in  ML 
simply  by  supplying  the  appropriate  [-]  and  //(-)  operations. 
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4.5.6  Example:  probability 

A  slight  refinement  of  the  nondeterminism  monad  permits  us  to  keep  track  not  only  of 
the  possible  outcomes  of  a  nondeterministic  evaluation,  but  also  their  relative  probab¬ 
ilities,  given  a  distribution  on  the  individual  choice  operations.  That  is,  a  probabilistic 
computation  of  type  a  is  represented  by  a  finite  set  of  pairs  (a,;,p,;),  where  a*  is  a  value 
of  type  a,  pi  €  (0, 1],  all  the  a*  are  distinct,  and  the  pt  sum  to  1. 

However,  this  example  also  illustrates  a  technical  problem  with  monads  as  a  struc¬ 
turing  tool  for  functional  programs,  as  opposed  to  describing  programming  language 
semantics:  the  definition  of  a  monad  requires  that  the  operations  y  and  -*  be  defined 
uniformly  at  all  types,  but  in  general  we  cannot  properly  implement  sets  of  higher-order 
values  because  elements  of  such  type  cannot  be  tested  for  equality. 

For  example,  we  cannot  algorithmically  identify  two  probabilistic  computations  like 
{(A.r..r.  1)}  and  {(Arc.  x,  0.  5),  (Xx.  x,  0.  5)},  even  though  both  represent  the  same  “def¬ 
inite”  identity  function.  Note  that  the  latter  variant  can  easily  arise  even  if  we  do 
not  allow  explicit  non-deterministic  choice  at  higher  types  -  consider  a  source  term  like 
let  y  =  amb  (3,  4)  in  Xx.  x  +  y  —  y. 

While  this  non-uniqueness  is  not  in  itself  a  problem  -  after  all,  we  cannot  observe 
functions  directly  -  we  need  to  ensure  that  any  ground-type  result  we  may  obtain  by  a 
series  of  applications  of  potentially  higher-order  probabilistic  functions  is  still  uniquely 
represented.  An  easy  way  of  achieving  this  is  to  always  represent  “active”  probabilistic 
computations  non-uniquely  using  list-nondeterminism,  but  then  only  expose  reification 
at  types  for  which  we  can  eliminate  duplicates: 

abstraction  ProbMonad  : 
sig 

include  MONAD 

val  to_t  :  (’a  *  real)  list  ->  ’at 
val  from_t  :  ’’at  ->  (’’a  *  real)  list 

end  = 
struct 

type  ’at  =  (’a  *  real)  list  (*  0 .0<p<=l .0 ;  sum(p)  =  1.0  *) 
fun  unit  a  =  [(a, 1.0)] 
fun  ext  f  ( []  :  ’a  t)  =  [] 

I  ext  f  ((a,p)  :  :  t)  =  map  (fn  (b,q)  =>  (b,p*q))  (f  a)  <§  ext  f  t 
fun  show’  [(a,  1.0)]  =  a 
I  show’  []  =  "" 

I  show’  ((a,p)  : :  t)  =  "<p:  "  ~  makestring  p  ~  ~  a  ~  show’  t 

fun  to_t  1=1  (*  could  do  some  sanity  checking  here  *) 

fun  tally  (a,p)  ([]:”at)  =  [(a,p)] 

I  tally  (a,p)  ((a’,p’)  : :  t)  = 

if  a  =  a’  then  (a,p+p’)  ::  t  else  (a’,p’)  ::  tally  (a,p)  t 
fun  from_t  t  =  fold  (fn  (h,l)  =>  tally  h  1)  t  [] 
fun  show  t  =  show’  (from_t  t) 
end; 

functor  ProbOps  (structure  R  :  RM0NAD  sharing  R.M  =  ProbMonad)  : 

sig 

val  choose  :  (’la  *  real)  list  ->  ’la 
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val  flip  :  real  ->  bool 

val  distribution  :  (unit  ->  ’’la)  ->  (’’la  *  real)  list 

end  = 
struct 

fun  choose  1  =  R. reflect  (ProbMonad.to_t  1) 
fun  flip  p  =  if  p  <=  0.0  then  false 

else  if  p  >=  1.0  then  true 
else  choose  [(true.p),  (false, 1 .0-p)] 
fun  distribution  t  =  ProbMonad. from_t  (R. reify  t) 
end; 

structure  ProbRep  =  Represent  (structure  M  =  ProbMonad) 
structure  FX  =  ProbOps  (structure  R  =  ProbRep)  open  FX; 

ProbRep. run  (fn  ()  =>  if  flip  0.3  =  flip  0.3  then  "same"  else  "diff"); 
(*  val  it  =  "<p:  0 . 58>same<p :  0 .42>diff"  :  string  *) 


Here  we  have  used  the  SML/NJ  abstraction  extension  to  hide  the  implementation 
of  the  type  t;  an  analogous  effect  could  be  achieved,  slightly  more  verbosely,  using  the 
standard  abstype  construct.  Also,  strictly  speaking,  the  above  only  gives  us  uniqueness 
up  to  permutation;  to  get  a  truly  unique  representation  we  actually  need  the  type  ’  ’a 
to  be  linearly  orderable,  not  only  supporting  an  equality  predicate. 

We  can  use  probabilistic  effects  to  solve  “textbook  problems”  such  as  finding  the 
distribution  of  the  total  number  of  heads  in  n  tosses  of  a  biased  coin: 


fun  toss  p  0  =  0 

I  toss  p  n  =  if  flip  p  then  1+toss  p  (n-1)  else  toss  p  (n-1) ; 
(*  val  toss  =  fn  :  real  ->  in t  ->  in t  *) 

distribution  (fn  ()  =>  toss  0.3  5); 

(*  val  it  =  [(0,0.16807) ,  (1,0.36015),  (2,0.3087),  (3,0.1323), 
(4,0.02835),  (5,0.00243)]  :  (int  *  real)  list  *) 


Of  course,  in  this  particular  case,  there  already  exists  a  simple  analytic  solution,  but 
the  “probabilistic  execution”  approach  also  handles  less  regular  experiment  protocols, 
where  very  dissimilar  branches  may  be  taken  depending  on  outcomes  of  probabilistic 
choices. 

Note  that  the  simulation  keeps  track  of  all  possible  computation  paths,  at  a  potentially 
exponential  cost  in  computation  time.  In  cases  where  the  same  net  outcome  can  be 
achieved  in  many  different  ways  (as  in  the  example  above),  it  is  therefore  often  useful  to 
add  an  explicit  wrapper, 


choose  (distribution  (fn  ()  =>  E )) 


around  such  a  subcomputation  E.  This  has  no  effect  on  the  result  computed  (almost  by 
definition:  it  is  an  instance  of  the  principle  p([E~\)  =  E ),  but  it  improves  efficiency  by 
consolidating  computation  paths  in  a  manner  analogous  to  dynamic  programming. 
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4.5.7  Example:  continuations 

Finally,  let  us  consider  the  continuation  monad  (for  an  arbitrary  but  fixed  answer  type). 
This  lets  us  define  both  escapes  and  composable  first-class  continuations.  We  already 
have  the  functor  ContMonad.  Let  us  create  a  specific  instantiation: 

structure  StringContMonad  :  MONAD  = 

struct 

structure  S  =  ContMonad  (type  answer  =  string)  open  S 
fun  show  t  =  t  (fn  x  =>  x) 

end 

functor  StringContOps  (structure  R  :  RMONAD  sharing  R.M  =  StringContMonad): 

sig 

val  mycallcc  :  ((’la  ->  ’lb)  ->  ’la)  ->  ’la 
val  myshift  :  ((’la  ->  string)  ->  string)  ->  ’la 
val  myreset  :  (unit  ->  string)  ->  string 

end  = 
struct 

fun  mycallcc  h  = 

R. reflect  (fn  k  =>  let  fun  c  a  =  R. reflect  (fn  k’  =>  k  a) 

in  R. reify  (fn  ()  =>  h  c)  k  end) 

fun  myshift  h  = 

R. reflect  (fn  k  =>  R. reify  (fn  ()  =>  h  k)  (fn  x  =>  x)) 
fun  myreset  t  =  R. reify  t  (fn  x  =>  x) 

end; 

structure  StringContRep  =  Represent  (structure  M  =  StringContMonad) 
structure  FX  =  StringContOps  (structure  R  =  StringContRep)  open  FX; 

StringContRep . run  (fn  ()  =>  makestring  (3  +  mycallcc  (fn  k  =>  6  *  k  1))); 

(*  val  it  =  "4"  :  string  *) 

StringContRep . run  (fn  ()  =>  "a"  ~  myreset  (fn  ()  => 

"b"  ~  myshift  (fn  k  =>  k  (k  "c")))); 

(*  val  it  =  "a bbc"  :  string  *) 


4.6  Related  work 

Different  notions  of  functional  or  composable  continuations  have  been  studied  by  a  num¬ 
ber  of  researchers.  Early  work  [.JD88,  FWFD88,  DF90]  presumed  explicit  support  from 
the  compiler  or  runtime  system  for  the  actual  implementation,  such  as  the  ability  to  mark 
or  splice  together  delimited  stack  segments.  However,  an  encoding  in  standard  Scheme 
of  one  variant  was  devised  by  Sitaram  and  Felleisen  [SF90].  Still,  this  embedding  was 
quite  complex,  relying  on  dynamically-allocated,  mutable  data  structures,  eq?-tests,  and 
the  dynamic  typing  of  Scheme. 

Another  explicitly  Scheme-implementable  notion  of  partial  continuations  was  pro¬ 
posed  by  Queinnec  and  Serpette  [QS91] ;  the  code  required  is  perhaps  even  more  intric¬ 
ate.  And  more  recently,  an  implementation  of  a  related  construct  in  Standard  ML  of 
New  Jersey  was  presented  by  Gunter,  Remy  and  Riecke  [GRR95]. 
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At  least  initially,  most  of  these  operators  appear  more  general  than  monadic  reflection 
for  continuations,  but  it  is  not  clear  if  the  additional  expressive  power  is  sufficiently 
useful  in  practice  to  justify  their  fairly  complex  implementations.  The  much  simpler 
construction  presented  in  this  chapter  uses  only  a  single,  statically-typed  cell  holding  a 
continuation,  perhaps  the  minimal  increment  over  call/cc  alone. 

Much  more  significantly,  however,  this  implementation  is  directly  derived  from  and 
related  to  the  original  specification;  other  efforts  gave  at  most  an  informal  argument  that 
the  (usually  operationally  specified)  control  construct  was  correctly  implemented  by  the 
code.  Given  the  relatively  complex  correctness  proof  for  even  the  very  simple  control 
operators  used  in  this  chapter  (A  and  #),  it  is  not  likely  that  any  of  the  alternatives 
would  be  easier  to  verify. 

The  term  metacontinuation ,  with  a  fairly  broad  meaning,  was  first  used  in  giving  a 
formal  semantics  to  a  notion  of  computational  reflection  by  Wand  and  Friedman  [WF88]. 
The  more  restrictive  usage  of  the  term,  where  the  metacontinuation  actually  arises  from 
a  standard  continuation-passing  transform  of  an  “almost-cps”  term,  is  due  to  Danvy  and 
Filinski  [DF90]. 

The  further  observation  that  the  metacontinuation  can  be  represented  by  a  storage 
cell  was  first  exploited  in  a  preliminary  version  of  the  present  work  [Fil94],  An  application 
of  this  technique  for  continuation-based  partial  evaluation  was  reported  by  Lawall  and 
Danvy,  who  found  that  a  call/cc-based  implementation  of  composable  continuations  uni¬ 
formly  outperformed  the  equivalent  explicit  continuation-passing  translation,  especially 
with  respect  to  heap  usage  [LD94], 

The  main  difference  between  the  variant  of  composable  continuations  considered  in 
this  chapter  and  the  previous  formulations  is  that  we  start  with  an  even  more  abstract 
specification  of  the  original  operators,  distinguishing  in  the  type  system  between  com¬ 
putations  with  and  without  control  effects.  Correspondingly,  the  definitional  translation 
only  has  a  non-trivial  effect  on  computations  of  the  former  kind. 

This  distinction  gives  us  a  very  simple  correspondence  between  composable  continu¬ 
ations  and  monadic  reflection  for  the  continuation  monad,  further  motivating  composable 
continuations  as  the  canonical  control  effect.  (The  change  was  also  partially  necessitated 
by  the  introduction  of  ambient  effects;  in  [Fil94],  the  target  language  of  the  definitional 
translation  was  assumed  to  be  effect-free  in  the  present  terminology.) 


Chapter  5 
Conclusions 


5.1  Summary 

We  have  analyzed  a  new  approach  to  incorporating  computational  effects  in  a  functional 
language.  In  many  ways,  it  combines  the  best  features  of  the  existing  “purely  functional” 
and  “imperative”  models  for  effects,  as  well  as  providing  a  basis  for  introducing  effects 
incrementally.  Let  us  recapitulate  the  main  properties  of  the  construction: 

Convenience.  An  important  advantage  of  monadic  reflection  is  the  ease  with  which  it 
fits  into  the  familiar  programming  paradigm  of  ML-like  languages.  There  is  essen¬ 
tially  no  up-front  cost:  programs  do  not  have  to  be  (re)written  in  any  particular 
style,  the  effects  used  do  not  have  to  be  settled  upon  in  advance,  and  we  can  directly 
use  the  existing  type  checker,  module  system,  etc. 

In  fact,  there  is  no  need  to  even  explicitly  mention  monads  when  writing  the  bulk 
of  the  program.  Typically,  the  programmer  simply  defines  the  desired  operations 
(such  as  raise  and  handle  for  exceptions,  pick  and  results  for  nondeterminism,  or 
spawn  and  yield  for  resumptions)  using  monadic  reflection  for  a  suitable  monad, 
then  expresses  the  program  in  terms  of  those  new  primitives  alone. 

The  visible  difference  from  a  “manual”  implementation  of  the  effects  in  terms  of 
continuations  and  state  (or,  even  more  markedly,  as  part  of  the  compiler)  is  the 
amount  of  effort  and  ingenuity  required.  Usually,  the  monad  specification  consists 
of  only  a  few  lines  of  simple,  effect-free  code.  Likewise,  the  exported  operations 
are  generally  a  simple  combination  of  the  reflection  and/or  reification  operators. 
We  never  have  to  think  about  capturing,  storing,  retrieving,  and  invoking  continu¬ 
ations  to  implement,  say,  a  backtracking  search;  all  the  required  low-level  code  is 
synthesized  mechanically  from  an  abstract  specification  of  nondeterministic  choice. 

Ease  of  reasoning.  Despite  its  apparent  “imperative”  nature,  monadic  reflection  can 
equally  well  be  viewed  as  a  technique  for  writing  “purely  functional”  programs 
in  a  more  concise  notation,  much  like  monad  comprehensions  [Wad92a],  In  fact, 
any  imperative  program  fragment  is  extensionally  equivalent  to  its  monadic-style 
counterpart,  in  the  sense  that  there  exist  language-definable  isomorphisms  between 
the  two  representations. 
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A  crucial  point,  however,  is  that  this  correspondence  to  monadic  style  is  a  means , 
not  an  end ,  for  reasoning  about  programs.  Simply  “being  expressible  with  a  mon¬ 
ad”,  or  “having  a  translation  into  purely  functional  code”  are  vacuous  properties, 
true  of  any  program  using  continuations  and  state  (since  both  are  monadic  effects), 
and  do  not  help  us  prove  anything  new.  Rather,  we  must  exploit  the  knowledge  that 
a  program  is  expressible  with  a  particular  monad,  with  a  more  restrictive  notion  of 
effects  than  the  continuation-state  monad  into  which  it  happens  to  be  embedded 
for  implementation  purposes. 

For  example,  in  an  ML-like  language  defined  by  exception-passing  on  top  of  par¬ 
tiality,  it  is  easy  to  argue  correctness  of  a  source-level  transformation  such  as 
fx  +  fx  =  2  x  f  x:  the  subcomputation  fx  must  either  succeed  with  a  value, 
raise  an  exception,  or  diverge;  in  all  three  cases,  the  two  expressions  are  equivalent. 
On  the  other  hand,  if  we  examine  only  a  hand-coded  implementation  of  exceptions 
in  terms  of  escapes  and  state  -  even  if  the  latter  effects  are  used  for  no  other  purpose 
in  the  program  -  we  cannot  argue  nearly  as  directly  that  common-subexpression 
elimination  is  a  valid  optimization  principle. 

Efficiency.  Execution  efficiency  is  an  important  concern  for  practical  uses  of  effects,  and 
monadic  reflection  usually  fares  significantly  better  than  an  actual  translation  into 
monadic  style.  If  effects  are  rare,  programs  run  at  full  speed  without  the  overhead 
of  explicitly  performing  the  administrative  manipulations  specified  by  the  monad, 
such  as  tagging  and  checking  return  values  for  exceptions. 

To  ensure  good  performance  of  the  reflection  and  reification  operators  as  well,  we 
do  need  to  assume  a  reasonably  efficient  implementation  of  call/cc  in  the  host 
language.  In  cps-based  compilers,  providing  a  cheap  first-class  continuation  facility 
is  generally  straightforward  [App92],  And  even  in  stack-based  implementations, 
good  techniques  exist  for  keeping  at  least  the  amortized  cost  per  call/cc  acceptably 
low  [HDB90]. 

Still,  if  a  particular  effect  is  heavily  used,  it  may  be  preferable  to  rewrite  the  program 
in  the  corresponding  monadic  style.  For  example,  if  the  parameter  provided  by 
an  environment  monad  changes  very  frequently,  we  should  make  it  an  explicit 
argument  to  all  functions  using  it.  Not  only  is  this  likely  to  be  faster  than  going 
through  the  store  on  every  access,  but  it  will  probably  result  in  a  clearer  program  as 
well.  Conversely,  of  course,  rarely-used  arguments  can  be  made  implicit  ,  improving 
both  execution  speed  and  clarity  -  the  latter  by  focusing  attention  on  the  few 
cases  where  some  value  changes,  rather  than  on  all  the  ones  where  it  is  merely 
propagated. 

In  either  case,  however,  the  changeover  need  not  be  done  all  at  once,  because  we 
can  use  reflection  and  reification  to  interface  between  program  fragments  using  the 
two  approaches.  Indeed,  the  best  solution  may  well  be  to  make  the  effect  explicit  in 
parts  of  the  program  that  use  it  heavily,  and  implicit  in  those  that  are  not  directly 
affected  by  it. 
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5.2  Future  work 

Several  opportunities  for  extensions  and  future  investigation  arise  naturally: 

Recursive  types  in  the  specification  language.  Even  though  our  language  for  de¬ 
fining  monadic  effects  was  simply  typed,  there  do  not  appear  to  be  any  fundamental 
problems  in  allowing  general  recursive  types.  In  fact,  the  logical-relations  proofs  in 
Chapter  4  already  handle  recursion  in  the  answer  type  for  the  continuation  monads 
using  invariant  relations,  and  similar  techniques  could  in  all  likelihood  be  used  in 
Chapter  3  as  well. 

However,  a  proper  treatment  of  recursive  types  would  probably  include  more  than 
merely  adding  the  //-types  from  Section  3.2.1  to  the  specification  language.  For 
example,  it  might  be  appropriate  to  also  allow  recursively-defined  computation- 
types. ,  i.e. ,  types  of  the  form  jib.  (3,  with  an  explicit  notion  of  computation-type 
variables  and  the  associated  extensions  to  generalized  let,  etc. 

Even  more  important,  we  would  want  a  general  treatment  of  recursive  monad  spe¬ 
cifications,  such  as  used  in  the  continuation-passing  translation  of  Definition  3.34. 
The  required  structure  seems  to  be  an  Lo-monad  in  the  usual  sense,  but  parameter¬ 
ized  by  an  L^-type.  This  would  allow  us  to  express,  for  example,  ML-style  ref -cells 
storing  procedures,  or  exceptions  carrying  non-ground  data,  without  introducing 
explicit  isomorphisms. 

Layering  effects.  Although  its  potential  was  not  fully  realized  in  this  thesis,  the  organ¬ 
ization  in  terms  of  ambient  and  focus  effects  should  generalize  directly  to  multiple, 
layered  effects.  In  other  words,  we  should  be  able  to  integrate  different  notions  of 
effects  in  a  single  language  by  a  series  of  nested  monadic  translations,  at  each  step 
taking  the  previous  focus  effect  as  the  new  notion  of  ambient  effect. 

Moreover,  this  layered  strategy  for  modularly  specifying  effects  promises  to  general¬ 
ize  to  a  modular  implementation  of  such  effects  in  terms  of  continuations  and  state. 
More  specifically,  we  would  first  relate  a  heterogeneous  tower  of  monads  to  a  tower 
of  continuation-monads  (applying  at  each  level  the  construction  in  Chapter  3),  then 
flatten  this  cps  tower  into  a  single-level  implementation  (as  in  Chapter  4),  with  a 
collection  of  cells,  each  holding  one  meta-continuation  of  the  hierarchy. 

Indeed,  an  apparently-working  implementation  based  on  this  strategy  already  ex¬ 
ists,  and  preliminary  investigations  into  both  its  theoretical  justification  and  prac¬ 
tical  usefulness  have  been  very  encouraging.  However,  time  constraints  made  it 
infeasible  to  include  a  treatment  this  generalized  construction  in  the  thesis.  Fully 
formalizing  and  analyzing  the  multiple-effect  case  is  therefore  left  as  future  work. 

Practical  effect-typing  for  monadic  effects.  While  one  of  the  goals  of  the  construc¬ 
tion  was  to  permit  a  direct  embedding  of  the  effect-enriched  language  into  ML, 
this  does  not  mean  that  we  could  not  take  advantage  of  a  more  refined  type  sys¬ 
tem.  Some  discipline  is  required  when  writing  programs  with  effects,  and  it  would 
be  useful  to  detect  violations  of  effect-stratification  statically,  rather  than  during 
program  execution. 
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Accordingly,  there  should  be  a  way  to  optionally  make  the  effects  used  by  a  piece 
of  code  manifest  in  its  type,  especially  at  module  boundaries.  We  could  of  course 
achieve  this  by  always  exporting  procedures  in  their  “fully  reified”  form.  Such  an 
approach,  however,  tends  to  be  impractically  verbose,  and  the  additional  conver¬ 
sions,  although  semantically  transparent,  may  impose  a  non-negligible  overhead. 
We  would  want  a  concise  and  unobtrusive  way  of  representing  that  same  informa¬ 
tion  in  direct  style. 

Existing  work  in  this  area  tends  to  consider  mainly  low-level  notions  of  effects 
(jumps  and  state  manipulation)  [JG89,  K.JLS87],  rather  than  application-specific, 
higher-level  concepts.  But  given  the  often  complex  relationship  between  a  monadic 
specification  and  its  imperative  implementation,  it  seems  highly  unlikely  that  an 
automated  analysis  based  on  the  latter  would  be  able  to  detect  a  higher-level  pattern 
such  as  an  exception-handling  system. 

Moreover,  current  effect-type  systems  are  generally  phrased  in  terms  of  Curry-style 
type  inference  (i.e.,  with  the  semantics  of  a  program  given  a  priori,  and  independ¬ 
ently  of  its  type).  The  reflection-based  approach  to  effects,  on  the  other  hand,  also 
seems  well  suited  for  Church-style  type  reconstruction  (where  type  information  is 
considered  an  inherent  part  of  the  program,  only  elided  for  conciseness),  as  already 
advocated  for  ML  in  [HM93]. 

5.3  Closing  remarks 

Perhaps  the  most  concise  way  of  stating  the  main  conclusion  of  this  work  is  that  a  func¬ 
tional  program  can  and  should  distinguish  between  specification  and  implementation  of 
computational  effects  -  as  it  already  would  for  any  other  abstract  data  type.  Oversim¬ 
plifying  grossly,  we  could  summarize  the  alternatives  by  following  Hegelian  triad: 

•  Thesis:  the  implementation  is  the  specification.  The  meaning  of  an  effect  is  fully 
determined  by  a  reference  implementation.  For  example,  a  Scheme  program  could 
be  written  with  intuitive  but  informal  abstractions  such  as  error  handlers,  back¬ 
tracking,  or  threads,  ultimately  defined  only  by  their  expansions  into  call/cc  and 
set! . 

•  Antithesis:  the  specification  is  the  implementation.  The  behavior  of  an  effect 
is  fully  determined  by  a  purely  functional  executable  specification.  For  example, 
a  Haskell  program  could  be  written  in  monadic  style,  expanding  into  explicit 
exception-passing,  success  lists,  or  resumptions. 

•  Synthesis:  the  implementation  is  related  to  the  specification.  An  effect  has  a 
declarative  meaning  and  an  imperative  behavior,  with  the  latter  obtained  from  the 
former  in  a  systematic,  but  not  necessarily  direct  way.  For  example  (but  by  no 
means  exclusively),  a  program  could  be  written  and  analyzed  in  terms  of  monadic 
reflection,  but  eventually  executed  using  effects  built  out  of  escapes  and  state. 

In  other  words,  the  tension  between  Haskell-style  monads  and  Scheme-style  primitive 
effects  need  not  and  should  not  be  resolved  in  unilateral  favor  of  one  or  the  other:  it  is 
precisely  through  their  interplay  that  the  best  qualities  of  both  are  exposed. 


Appendix  A 

Properties  of  the  Predomain  Model 


In  this  chapter  we  summarize  a  few  auxiliary  results  about  the  predomain  semantics, 
needed  in  Chapters  3  and  4,  but  somewhat  tangential  to  the  main  development.  Most  are 
fairly  simple  adaptations  of  standard  domain-theoretic  results  to  our  predomain  setting. 

A.l  Recursive  type  definitions 

The  proof  that  all  recursive  type  equations  have  solutions  in  the  predomain  semantics 
hinges  on  exhibiting  for  any  type  constructor  a  suitable  functorial  action  in  the  category 
of  domains  and  strict  continuous  functions.  That  is,  in  addition  to  the  evident  action  on 
objects,  we  need  an  action  on  morphisms. 

Although  we  could  construct  such  functors  directly  in  the  model,  using  the  standard 
notation  for  continuous  functions,  it  seems  more  convenient  and  consistent  to  use  the 
existing  term  syntax  for  effects  (fixed  to  be  partiality)  in  the  definitions,  and  only  consider 
the  denotations  of  the  constructed  terms  in  the  end. 

For  the  purposes  of  this  appendix  only,  let  us  therefore  extend  our  term  syntax  by 
introducing  the  additional  computation-type  constructor  ±a  and  term  constructors  XM 
and  letx  x  -<=  Mx  in  M2  with  types: 

T  b  M  :  a  T  h  Mi  :  xa  broh  M2  :  3 
T  h  XM  :  x«  T  h  letx  x  4=  Mi  in  \12  :  i 

analogous  to  the  existing  ambient  effects,  but  always  referring  to  the  partiality  monad. 
The  letx  is  actually  more  like  the  generalized  let))  than  like  let°,  because  the  result  can  be 
of  any  computation- type.  We  omit  the  explicit  type  subscript  in  let  .  however,  because 
we  already  have  a  uniform  semantic  characterization  of  its  meaning  at  all  pointed  types: 

=  C[a]\ 

C{\Mf(p)  =  up  {C{Hlf{p)) 

£[letx  x  -<=  Mi  in  M2je(p)  =  (Xa.  C\M2\e(p[x  i->-  a]))*(£[Mi]fl(p)) 
where  /+  is  the  generalized  strict  extension  from  Section  2.1.3 (lifting) . 
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For  embedding-types,  we  also  define  a  general  case-construct,  dispatching  among  all 
the  possibilities  in 

TUM-.m  Vz  e  I.  T,  x:  K(z)  \~  M(i)  \  a. 

T  h  cas e(M,i.  Xj.  Ai(i))  :  a 

with  semantics 

£[case(z.M,  i.Xi.  M(i))f  (p)  =  C,\M{ij\6  (p[xi  a*])  when  £{M]°{p)  =  (f,a,,;) 

Again,  this  case  is  never  used  in  writing  actual  programs;  it  merely  gives  us  a  convenient 
way  of  referring  to  semantic  entities  in  the  predomain  model. 

Definition  A.l  For  any  value-type  a  and  computation-type  (5  over  {a}  in  L\  (%. e. ,  L q 
extended  with  an  empty  type),  we  define  a  type  constructor  <f>a.Q,(-,  -)  and  a  cornputation- 
type  constructor  ’fa.Jg(-, -)  by 

$a.„(a_,a+)  =  «{cA/a~,  a+/a+}  and  VE'a./? (cv  ,  «+)  =  /3{ot~/a,~,  o+/a+} 

where  a{a' / a+}  means  a  with  a'  substituted  for  all  positive  occurrences  of  a,  and  ana¬ 
logously  for  negative  occurrences. 

Further,  we  define  term,  constructors  $a.Q(-,  -)  and  ,  •)  with  types: 

f  :  q1  — >  ±a2 _ f+  :  af  — > 

$a.a(/A/+)  :  $a.a(a^;a^)  "^a.a  Al  >  «2  ) 

/~  :  al  ->•  ±a2  f+  '■  ai  ->•  ±Q;2" 

’fa ,/3(/A/+)  :  ’fa./3(«2AQl  )  ^  ^a.0 ) 

as  follows: 

$a.a (/A/+)  =  Aa.  f+  a 
®a.t  {ft  )  =  An.  At, 

$a.i(r,/+)  =  Au.x<) 

$a.alXQ2(/_,/+)  =  Ap.letX  Si  «=$a.01(/^/+)(fstp) 

in  letx  x2  <^=  <f  a.Q2  (/“,  /+)  ( snd  p)  in  x(:ci,  a;2) 

$a.o(/A/+)  =  A^.x^ 

$a.a1+a2(/A/+)  =  As.  case  (s,  rE!.letx  T/1  ^$a.ai  (/-,/+)  Xi  in  x(  ini  t/i), 

^2-letx  y2  <=  (ha.a2(/_,/+)^2  in  x(inrp2)) 

$a.s  n(/A/+)  =  As.  case  ( s.  / .  .  let  •  //,  <  <I>.,.N(<)  ( f  .  /  '  )  :ry  in  x(irvpi)) 

^ArJ+)  =  A/t.  (M/a  ;(/  ./•)/,) 

’fa  :Af-J+)  =  Am.  let°  x  m  in  letx  p  -<=  $a.a(/_,  /+)  a:  in  °y 
*«.,(/  ,:/•)  =  An.  () 

'IA/;,  •  j2(./'  ,  /+)  =  Ap.  (\fa.Jg1(/_,  /+)  (fstp),  ^a./32(/  ,  /+)  (snd  p)) 

’fa .a-^Af~J+)  =  Ap.Ax.letx  p<^$a.a(/+,/~)x  in  ^(/^/^(pp) 
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A  few  simple  properties  of  these  definitions  are: 

Lemma  A. 2  (1)  When  a  does  not  occur  free  in  a  or  [3  then 

AfAf+)  =  A aAa  'I'U./'  -f)  =  A b.b 

More  generally,  (2)  the  type-directed  actions  are  compositional: 

‘l>a,,(<l>a,v'(.r.  r  ),  $a  .a'iffi  f+  ) )  =  <Wa'/a}  (/“,  f+  ) 

^a.  •  D,  $a.a'(r  ,  /+))  =  a }  (/  ,  /+) 

Finally,  (3)  the  definitions  are  functorial  in  the  following  sense: 

Qa.cfiXxAx,  XxAx)  =  A  aAa  ’La.^Aic.  Ac,  Xx.  ±x)  =  A  b.b 

$a.a(Ax.  let1  y  <=  /,  x  in  ffi  y,  Xx.  let1  y  <=  ff  x  in  /2+  y ) 

=  Aa.  let1  r  <=  Qa.cfiff  i  fi)a  in  /2+)  r 

^a./3(A.r.  let1  y  4=  /f  x  in  ffi  y,  Xx.  let1  y  <=  ffi  x  in  ffi  y) 

=  Xb.  4.0  ( /f ,  /2+ )  ( ^a./3  ( /2“ ,  ft )  b) 

(i.e.,  <&a.a(_,  _)  is  an  endofunctor  in  the  Kleisli  category  of  the  lifting  monad,  while 
'I'a..^-.  -)  is  a  functor  from  the  Kleisli  category  to  the  underlying  one). 

Proof.  Simple  induction  on  a  and  (3  in  all  cases.  Note,  however,  that  verification  of 
the  value-product  case  of  (3)  relies  on  partiality  being  a  commutative  effect.  ■ 

We  can  also  define  an  “ordinary”  functorial  operation  on  functions  between  lifted 
types: 

Definition  A. 3  When  g~  and  g+  are  strict  functions  (i.e.,  rigid  with  respect  to  1- 
effects),  we  define  the  term  constructor 

g ~  :  ±af  — >■  ±af  g+  :  ±af  — >■  ±af 

lK.JH  ■■  !/')  :  ' ‘I’a.n  (n-J.  O',1  )  >  '  <I>a.n  K  .  02  ) 


by 


a(g  ,  g+)  =  Aju.let1  x  <=  m  in  $aa(Xx.g  (  ./•).  Xx.g  '  (  ./•)).?; 


We  then  have: 

Lemma  A. 4  -)  is  functorial  in  the  following  sense: 

<„(id,id)  =  id 

o  sf, at  ° at)  =  $L(sf *9*)°  ®L(S2 . at ) 

Proof.  Simple  verification,  using  Lemma  A. 2 (3): 

<f>a  Q(id,  id)  =  Am. let1  x  <=  m  in  <&aoi{\xAx,  \x.±x)x  =  Am. let1  x  ■<=  m  in  (A a.±a)x 
=  Am.  let1  x  <=  m  in  ±x  =  A m.m  =  id 
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$£Q(s2  °9i  ,gt  °9i)  =  Am.letx  x<=m  in  $a.a(Aa.g2  (g1  (±a)),  \a.g%  (gf  (±a)))  x 
Am.  let 1  a:  <=  m 

in  4>a.Q(Aa.letx  y  4=  g]  (xa)  in  g2  (xg),Aa.letx  y  <=  gf  (xa)  in  gf  Vy))x 
=  Am.  let x  x  4=  m 

in  letx  r  -4=  <ha.a(A y.g2  (xg),  A a.gf  (xa)):r  in  $a.«(Aa.g/  (xa),  Xy.gf  (xg))r 
=  Am.letx  r  4=  (letx  a;  4=  m  in  $a.Q(Ay.g^"  (xg),  Aa.g/  (xa))a:) 
in  $a.a(A a.gf  (xa),A y.gf  (xg))r 

=  Am.$f  Q(y];,y+)($ia(^,y+)m)  =  $a.Q(g/,  g£ )  °  $£Q(g/,  Si" ) 
where  f  uses  that  for  a  strict  g, 

gm  =  g  (letx  a;  4=  m  in  Ac)  =  letx  x  4=  m  in  g  (Ar) 


Let  us  also  recall  some  elementary  properties  of  least  fixed  points: 

Lemma  A. 5  Let  fix#  :  (B  — >■  B)  — >■  B  denote  the  least- fixed-point  operator  for  a  pointed 
cpo  B.  Then 

1.  For  any  continuous  f  :  B  — >■  B  and  g  :  B'  — >■  B1 ,  and  strict  continuous  h  :  B'  — >■  B 
with  f  o  h  =  h  o  g,  fixB(/)  =  h{f\xB>{g)). 

2.  For  any  continuous  f  :  B  — >■  B'  and  g  :  B'  — >■  B,  fi x#(g  °  /)  =  g(fix£/(/  o  g)). 

Proof. 

1.  Follows  directly  from  the  definition  of  fix: 

mixB'is))  =  mLIs'I-LbO)  =  U.M9’UbO)  =  U./'(MiB.))  =  U./'Ub) 

=  fi  XbU) 

2.  (We  cannot  simply  use  the  above  result  here,  because  g  is  not  necessarily  strict.) 
Let  x  =  fi Xfl/(/  o  g)  and  g  =  fix#(g  o  /).  First,  since  g(x)  is  a  fixed  point  of  g  o  / 
(because  (g  o  f){g{x))  =  g{{f  o  g)(x))  =  g{x)),  we  have  y  C  g(:r).  Analogously, 
since  /(g)  is  a  fixed  point  of  /  o  g,  x  C  /(g),  and  hence  by  monotonicity  of  g, 
g(;r)  A  g(/(g ))  =  g.  And  thus,  since  C  is  a  partial  order,  we  get  g (a: )  =  g. 


Although  for  the  purposes  of  Chapter  3,  all  we  need  is  a  solution  to  the  type  equa¬ 
tion  (not  necessarily  the  least  one),  for  Chapter  4  we  will  also  need  that  the  relevant 
isomorphism  satisfies  an  additional  equational  property: 

Definition  A. 6  Let  Cpo±  be  the  category  of  pointed  epos  (domains)  and  strict  continu¬ 
ous  functions.  Let  F  :  Cpo)/  x  Cpo±  — >•  Cpo±  be  a  functor  (we  call  such  an  F  a  mixed 
functor  in  Cpo±y);  it  is  locally  continuous  if  its  action  on  morphisms  is  continuous.  A 
minimal  invariant  for  F  is  an  object  X  together  with  an  isomorphism  i  :  F(X,  X)  — >■  X 
such  that 

fix  y_j,  y  (A h.i  o  F(h,  h)  o  i  1 )  =  id x 
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One  can  show  that  the  standard  inverse-limit  construction  for  solving  recursive  do¬ 
main  equation  actually  yields  minimal  invariants: 

Theorem  A. 7  Every  locally  continuous  mixed  functor  in  Cpo±  has  a  minimal  invari¬ 
ant. 

Proof.  See  [Pit99] .  ■ 

Using  this,  we  get  for  our  predomain  language: 

Corollary  A. 8  Every  recursive  type  equation  in  L\  has  a  solution  in  the  predomain 
model ,  i.e.,  for  any  parameterized  type  hjaj  a  type,  there  exists  a  cpo  A  with  an  iso¬ 
morphism  i  :  £[o]aM'"4  — >■  A.  Moreover,  interpreting  n&.a  as  A,  rolla  a  as  i,  and  unrolla  a 
as  *_1,  the  following  equation  is  satisfied  in  the  model: 

(A/.  Ao. letx  x  4=  $a.«(/, /)  ( unrolla.a a)  in  x( rolla.Q:c))  =  Aa.xa 

Proof.  Every  pointed  cpo  is  isomorphic  to  a  lifted  cpo.  So  we  can  use  Theorem  A. 7 
with  the  functor  given  by 

=  (£[$a.Q(  ar,a+)]a^^’a+^A+)±, 

F{g  :  Ax  x  — >  A2  ±,  g+  :  Af  j_  — >■  A2  _l) 

=  C\^ia  (X-,X+)P^  X *r4 ^At(.[x-^g-,X+^g+}) 

to  obtain  a  pointed  cpo  A±  with  an  isomorphism  j  :  (£[a]aM'^)j_  — >■  Ax.  Moreover,  since 
j  is  an  isomorphism,  it  both  preserves  and  reflects  _L,  and  must  hence  be  expressible  as 
j  =  i±  =  Am.  let x  x  4=  m  in  ±(ix)  for  some  isomorphism  i  :  £[a]aM'"4  — >■  A. 

Further,  we  get  the  minimal  invariant  property  for  i  from  the  minimal  invariant 
property  of  j  wrt.  *f)aa(-,  -),  using  Lemma  A. 5(2)  to  rearrange  the  fix  body: 

fix  (Af .  Ax.let1-  r  $a.Q  (/,/)(</>  z)  in  x(</>r)) 

=  fix  ((A g.  A x.g^x))  o  (A/.  Am.letx  x  4=  m  in  letx  r  4=  $a.Q(/,  f)(iftx)  in  ±(4>r))) 

=  i^gAx.g^x)) 

(fix  ((A/.  Am.  letx  x  <=  m  in  letx  r  4=  <f>a.Q(/,  f)  (ip%)  in  x(<^r))  o  (A g.  Ax.g  (±x)))) 
=  Ax.  fix  (A g.  Am.  let x  x  4=  m 

in  letx  r  4=  $a.a(A x.g£x),  Ax.g^x))  (tpx)  in  x(^r))  (x:r) 

=  Ax.  fix  (A g.  Am.letx  x  4=  m  in  letx  r  4=  Q%a(g,  g)(±('ipx))  in  x(^r))  (Lr) 

=  Ax.  fix  (A g.  Am.  (Am.  let  x  r-^m  in  ±((fr))  ($£  a(g,  g)  (letx  x  4=  rn  in  ±(ipx))))  (Ur) 
=  Ax.  fix  (Ag.  Am.j  (^f  a(g,  g)  (M1  m)))  (±x)  =  Ax.\d  (x x )  =  AxAx 


A. 2  Admissible  relations 

In  this  section  we  review  the  properties  of  (computation-)admissbile  relations  in  the  cpo 
semantics;  in  particular,  we  show  admissibility  of  the  key  relation-forming  constructs. 

Let  there  be  given  a  relational  correspondence  between  predomain  interpretations  C 
of  L  and  £  of  £  (Definition  3.16).  Most  notably,  admissibility  is  then  preserved  by 
formation  of  inverse  images  and  intersections  (e.g.,  [Pit99] ) : 


A.2.  ADMISSIBLE  RELATIONS 


123 


Lemma  A. 9  Recall  that  a  (computation-) admissibile  relations  between  closed  types  a 
and  a7  is  a  (pointed)  chain-complete  relation  between  epos  £[a]  and  £7[a7].  We  then 
have: 

1.  When  R  E  ARel(a,  a7),  (xi\oi\i...,xn\oin)  h  M  :  a  and  (a/ :  a( , . . . ,  x'n, :  a'n, )  h 
M'  :  a7  are  terins  of  L  and  L'  respectively,  and  for  all  i  >  2,  ax,  E  Va l^/a,;)  and 
o' x\  E  Val £/(a7),  the  relation  R  \  E  Rel(a1,a/1)  given  by 

ai  IR  a(  ^  \RaO*a<"’ 


is  admissible. 

Moreover,  when  ax  and  a[  ai'e  computation-types,  R  is  computation- admissible, 
and  the  functions  A x\,Ma  and  A xl1.Mla  are  rigid,  then  R \  is  also  cojnputation- 
admissible. 

2.  When  ( Rj)je.j  is  an  arbitrary  (not  necessarily  finite  or  even  countable)  family  of 
admissible  relations  between  a  and  a7,  the  relation  Clj^j  Rj  A  admissible,  where 

a  (Hjej  -^j)  a>  £  -A  a  Rj  a' 

Moreover,  if  each  Rj  is  computation- admissible  then  so  is  f]jGJRj. 

Proof.  Both  parts  are  fairly  simple: 

1.  Define  the  continuous  functions  /  :  £[«i]  — »  £[a]  and  f  :  C  [a7,  ]  — >■  £7[a7]  by 
/  =  Aai.£[M](«[:ri  a1,x2eE  ax2. . . ,  xn  i->-  axn]) 


and 

f  =  Aa^ .  C'  \M'\  ( •  [a/  eE  a),  x'2  eE  a'x'2  &'x'ni } ) 

Then  ai  R.\  a\  iff  f(ai)  R  /7(a71). 

Now  let  (aij)jgw  and  (a'n)^  be  chains  in  £[aj]  and  ^[aj],  respectively,  such  that 
for  all  i  E  u,  an  Ri  a'u ,  i.e. ,  /(an)  R  /'(a7^).  By  monotonicity  of  /,  the  sequences 
{f(au))im  and  (f'(a\i))i-w  then  form  chains  in  £[a]  and  £7[a7],  and  since  R  was 
assumed  chain-complete,  we  have 

U, /(“«)  «U, /'(»'«) 

By  continuity  of  /  and  /7,  this  is  equivalent  to 

/(U“h)-r/'(U“'u) 

which  says  that  U*  an  R\  U  a'n,  meaning  that  R\  is  chain-complete. 

Further,  to  show  Ri  pointed,  we  must  show  /(_L)  R  /'( _L),  which  follows  from 
pointedness  of  R  and  the  fact  (Proposition  2.13)  that  a  rigid  function  is  strict. 
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2.  Let  Rj  be  a  family  of  chain-complete  relations  between  epos  £[ck]  and  £,[q'/],  and 
let  (ai)iGoJ  and  (a')jgw  be  chains  componentwise  related  by  the  intersection  R  of  all 
the  Rj.  That  is, 

Vz  €  u).  Vj  G  J.  a,;  Rj  a[ 

Exchanging  the  two  universal  quantifiers,  we  get 

Vj  G  J.Vi  6  w.  a,;  Rj  a' 

Now,  since  each  Rj  was  assumed  chain-complete,  this  implies 

V./  e  J.  U;  <n  Rj  |_|;  ai 

And  thus,  |_l,  «?;  (f| je.j  Rj)  U,  as  required  to  show  chain-completeness  of  R. 

Similarly,  if  each  Rj  relates  Ec\p\  and  T alp1},  then  so  must  their  intersection,  and 
thus  fljg  j  Rj  is  pointed. 


We  can  also  show  admissibility  of  the  standard  relational  actions  of  the  type  con¬ 
structors  (where  it  does  not  already  follow  directly  from  the  previous  lemma): 

Lemma  A.  10  If  the  R's  are  admissible  relations,  then  so  are  (1)  /'  and  (2)  R\  +r  R2 
(defined  as  in  Lemma  3.18),  and  (3)  the  E \Rj,  given  by 

s  (E \Ri)  s  -<=>-  3 i  G  I.  3 a,;  Rj  a \.  s  =  in,;  a*  A  s'  =  in,;  a) 

Moreover,  if  relation  extension  is  taken  as  relation-lifting  (from  Proposition  3.21),  then 
(4)  °R  is  computation-admissible. 

Proof.  The  relations  determined  by  the  definitions  in  each  case  can  be  written  as: 

A  =  {(n,  n)  |  n  e  N} 

Ri  +1  R2  =  {((1,  cq),  (1,  Qi))  |  (cq,  a\)  G  i?i}  U  {((2,  (22),  (2,  a2))  \  (ag-,  a2)  G  R2) 

S \Rj  =  {((z,  a*),  (z,  a'))  |  i  G  I,  (a,,  a')  G  Rj} 

°R  =  {(up  (a),  up  (a7))  |  (a,  a')  G  R}  U  {(_L,.  T)} 

We  then  check  each  case: 

1.  Case  A .  Since  the  epo  N  of  natural  numbers  was  discretely  ordered,  any  chain  in 
N  must  be  constant,  so  least  upper  bounds  of  componentwise  related  chains  are 
obviously  also  related. 

2.  Case  Ri+rR2.  A  chain  in  A1+A2  must  lie  entirely  within  one  of  the  injects.  Assume 

wlog.  that  it  is  of  the  form  ( ( 1 .  rq)  ),vt.  for  some  chain  (a,;),;ew  in  A\.  Analogously, 

the  related  chain  must  be  of  the  form  ( ( 1 .  with  eq  If  a[.  By  assumption  on 

R.\ ,  |_l, Ri  Ui.a'i-  The  result  then  follows  by  observing  that 

□,;(!,  a*)  =  (l,Uiai)  (^1  +  ^2)  (l,Uiai)  =  UM’O 
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3.  Case  E \Rj,  is  analogous  to  +r,  only  with  the  set  of  tags  taken  as  I  instead  of  {1,  2}. 

4.  Case  °R.  Let  (//;,;), ..-w  and  (m')jgaj  be  chains  such  that  m*  (°R)  m ' .  There  are  then 
two  possibilities.  It  could  be  that  for  all  z,  m*  =  JL^±  and  rn't  =  T At  In  this  case, 

Ui  mi  =  =  Ui  m'i 

by  the  second  disjunct  of  the  definition,  and  we  are  done.  Or  there  exists  an  i0  >  0, 
such  that  for  all  i  >  z0,  =  up  (a,;)  and  m-  =  up  (a')  for  some  a j  R  a'.  By 

definition  of  the  ordering  in  A± ,  the  a,;  form  a  chain  (if  up(cq)  C  up(ai+1)  then 
a,  C  a,;+ 1).  Analogously  for  the  a'.  Because  i?  was  assumed  chain-complete,  we 
have  U i>i0ai  R  U i>i0a'i-  And  since  the  initial  segment  of  As  in  a  chain  does  not 
affect  its  least  upper  bound,  we  get 


U, mi  =  U>io  UP(o)  =  Up(LL;n  O)  (°R)  Up(U,;>,;n  O  =  U?;>,;n  UPK)  =  U 


J*>*D 


i>i  o 


■ii>io 


rri- 


Also,  directly  by  the  second  component  of  the  definition,  °R  is  pointed. 


And  finally,  we  can  verify  our  fixed-point  induction  principle: 

Lemma  A.  11  Let  S  be  a  computation- admissible  relation  between  /3  and  (3' .  Let  f  £ 
Val£  (/?—)►/?)  and  f  £  Val  be  such  that\/b  S  b'.  fb  S  fit .  Then  fi  xp  f  S  fix^  f. 

Proof.  We  have  A[fix/3:r](«[.r  i-)-  /])  =  U;  /'(  I  £l;  )•  and  analogously  for  f.  Since  in 
particular  S  is  admissible,  i.e. ,  chain-complete  in  the  model,  it  suffices  to  show  that  for 
all  i  >  0, 

f(Rcm)  s  f'\Tcm) 

This  follows  by  a  simple  induction  on  i.  For  i  =  0,  we  get  the  result  from  pointedness 
(computation- admissibility)  of  S.  And  for  the  inductive  step,  we  use  that  if  /*(_L)  S  fn( _L) 
then  by  assumption  on  /  and  /', 

f+1(X)  =  f(f(  T))  S  /'(/"(  J))  =  /,m(T) 


A. 3  Isomorphisms  of  recursive  types 


The  definition  of  .«(/A/+)  allows  it  to  act  on  partial  functions  (i.e.,  total  functions 
into  a  lifted  cpo);  we  need  this  generality  for  solving  recursive  type  equations,  because 
the  approximants  will  not  be  total.  But  when  the  type-directed  functor  acts  on  known 
isomorphisms  between  epos  (not  necessarily  pointed),  a  simpler  definition  is  possible: 


Definition  A. 12  When  ip  is  a  term  constructor  denoting  an  isomorphism  (e.g.,  roll  or 
unroll ),  we  define  term  constructors  <&\,.a(p>)  and  H/a .p(t)  types: 


ip  \  OL\  M  OL2 

<^>a.a(<^)  :  i/a}  ^4  a{«2/a} 


:  «i  A  «2 

1J,a./3(<^)  :  /5{o:i/a}  ^4  / 3{ol2/A\ 


and 
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as  follows: 


$a.a ((f)  a 

$L  (tp)n 
$h{(p)u 
<l>a...,x«a(r  )/' 
®l.o{(p)z 

c5a.Qi+a2  (T)  s 
s 

*Lp(<p)b 


pa 

n 

0 

<®Loi  (<p)  ( fst  p),  $Loa(vO  ( snd  p)) 

z 

case  (s,ai.  ini  ($a.ai  (b)  ai),  a2.  ini  ($a.«2  (b)  a2)) 
cas e(s,i.di.  in*  (®LN(*)(^)at)) 


’J'a.a(b)™' 

'l,a.;ux;.!(y)/' 


let”  x  -<=  m  in  °($a.Q(^)a:) 

0 

<^1/0!  (<p)  ( fst  p),  ^a./3o  (<p)  ( snd  p)) 
Xx.'Ffifip)  (5-($*.a((^_1).r)) 


Lemma  A. 13  The  functorial  actions  on  isomorphisms  are  related  to  their  general  coun¬ 
terparts  as  follows: 


iCtrffl)  =  $a.a(A$.-L(p  1x),Xy.±{(py))a 
.p{<p)b  =  '&a.i3(>'x-±{<p-1x),\y.±(<py))b 


Proof. 


Straightforward  induction  on  a  and  (3. 


Note  also  that  we  have  (<p))  =  $1^/,}^). 

Lemma  A. 14  Let  F  and  G  be  type  constructors  of  L\  (not  necessarily  covariant),  and 
let  a  =  pa.F(Ga)  and  a'  =  pa'.G(Fa')  be  the  solutions  to  the  corresponding  recursive 
type  equations.  Then  in  the  predomain  model,  there  exists  an  isomorphism  :  Ga  M-  a' , 
which  further  satisfies  the  following  two  (equivalent)  coherence  equations: 

X-.Ga  b  rolla'.G(Fa')  (^'.G(Fa')(x)  ($a.Ga(unrolla.F(Ga))^))  =  Xx  ■ 

y:a  b  $a.Ga(rolla.F(Ga))  (^a'.G(Fa')(x_1)  (  unroll  a'.G(Fa')  v))  =  X_1  U  ■  Ga 

Proof.  When  p  :  a\  M-  «2  is  a  term  constructor,  we  define  the  function 

p)  :  J"aq  -x  ^a-i  =  Am±Qblet±  x  <=  m  in  ^(px) 

For  terms,  take  F(f~,  f+)  =  Fa(/_,  f+ )  and  also  write  F(f)  for  F(f,  /).  Analogously 

for  G.  Further,  we  define  the  usual  abbreviations  fi  =  rolla.F(c?a)  and  =  rolla'.G(Fa')) 
with  ip  and  ip'  for  the  inverses. 
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Now  let  i  =  $  :  ±F(Ga)  — >■  ±a  and  j  =  <fi'$  :  ±G(Fa')  — >■  -W  be  the  minimal  in¬ 
variants  for  the  corresponding  functors.  We  first  show  that  there  exists  an  isomorphism 
l  :  ±G(a)  — >■  ±a'.  Take 

(/',/)  =  fix  {\{h±a'^±Ga,  k±Ga^±a'). 

(G(z-\z)oG(F(Ek),F(k1h))oj-\joG(F(Eh)1F(h1k))oG(z^-1))) 

We  want  to  show  that  !'  is  actually  the  two-sided  inverse  of  l.  Accordingly,  consider  the 
strict  function  c  =  A (h,  k).  k  o  h.  Lemma  A. 4  then  gives  us: 

c  o  (X(h,  k).  (Gi'E1  ,i)  o  G(F(h,  k),F(k,  h))  o  j-1,  j  o  G{F{k,  h),  F{h,  k))  o  G{i,  A1))) 

=  A(/i,  k).jo  G(F(k,  h),  F(h,  k))  o  G[i ,  A1)  o  G(t_1  A)  o  G(F(h,  k),  F{k,  h))  o  j-1 
=  X(h,  k).j  o  G(F(k,  h),  F{h,  k))  o  cjr1  o  «,  r1  o «))  o  G(F(/i,  k),F(k,  h))  o  j -1 
=  X(h,  k).j  o  G(F(k,  h),  F(h,  k))  o  G(\d±FGa ,  id±FGJ  o  G{F{h,k),  F{k,h))  o  j-1 
=  X(h,  k).j  o  G(F(k,  h),  F(h,  k))  o  \d±GFGa°  G{F(h,k),F(k,h))  o  j-1 
=  X(h,  k).j  o  G(F(h,  k)  o  F(k,  h ),  F(h,  it)  o  F(Jfe,  ft))  o  j-1 

=  Aft,  k).j  o  G(F(k  o  h,  k  o  h),F(k  oh,k°  h))  o  j-1  =  A(ft,  k).j°  G(F(k  o  h))  o  jT1 
=  A(ft,  A:).  (A/,  j  o  G(F(f))  o  j-1)  (k  o  h )  =  (A/,  j  o  G(F(/))  o  r1)  °  e 

From  Lemma  A. 2(2)  and  a  let-simplification,  we  obtain  that 

so  by  Lemma  A.5(l)  and  the  fact  that  j  is  a  minimal  invariant  for  GF,  we  get 

l’  ol  =  c(fix  (A(ft,  k).  •••))  =  fix  (A  f.j  o  G(F(f))  o  j-1)  =  id  =  id;, 

In  the  other  direction,  taking  d  =  A (h,  k).  h  o  A:,  we  similarly  get: 

d  o  (A  {h,  k).  {G(i\  i)  o  G(F(h,  k),  F{k,  h))  o  j-\j  o  G(F(k,  h),F{h ,  k))  o  G(i,  i  '))) 

=  A(ft,  k).  G{i  \  i)  o  G{F(h,  k),F(k,  h))  o  j-1  o  j  o  G{F{k,  h),  F{h,  k))  o  G{i,  A1) 

=  \{h,k).G{i-lG)  oG(f(M)T(M))  oG{F{k,h),F{h,k))  oG(i,r1) 

=  \(h,k).G(i-xH)  oG{F{hok,hok),F{hok,hok))  oGft.f1) 

=  (Ag.  <T/(/  ',/)  o  G(F(g,  g),F(g,  g))  o  G(i,  r1))  o  c' 

=  (\g.G(io  F(g,g)  oi  1,i°  F(g,g)  oi  1))  o  d  =  (Xg.  G(i  o  F{g)  o  i  1))  o  d 

And  thus  we  have,  using  both  parts  of  Lemma  A. 5  and  the  minimal-invariant  property 
of  i: 

lol1  =  d  (i\x(X(h,k).  ■  •  •))  =  fix  (Xg.  G(i  o  F(g)  o  A1))  =  G(fix(A/A  o  F(G(f))  of1)) 

=  G(id±Q)  =  id±Ga  =  idjt,Q 

We  can  thus  take  to  be  the  unique  isomorphism  such  that  y}  =  l. 

Further,  knowing  that  l  and  l1  are  actually  inverses,  we  get  the  second  part  of  the 
result  by  unrolling  their  fixed-point  definition  once: 

(*',  l)  =  (' )  o  G(F(l',  l),  F(l ,  l'))  o  j-\j  o  G(F(l ,  0,  F(r,  /))  °  G(t,  W1)) 

Now,  take  advantage  of  the  following  simple  relationship  between  the  functorial  ac¬ 
tions  on  an  isomorphisms: 

lK  Am.letx  x  <=  m  in  ±(y)_1a:),  Am.letx  «  <=  m  in  x( (px )) 

=  Am.letx  x  <=  m  in  4>a.Q(Aa:.let±  x  <=  ±x  in  ±((p~1x),  ■  ■  ■  ip  ■  ■  ■) x 
=  Am.letx  x  <=  m  in  $a.Q(A2:.±(<p_1a:),  A xP(ipx)) x 
=  Am. let x  x  <=  m  in  ±($l.a(p)x)  = 
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From  this  we  get: 

$  =  l  =  joG(F(l,l'),F(l',l))oG(i,r1) 

=  ^°<Ga(<Fa(xi,X-li),<Fa(x-li,xi))o  <Ga(A^) 

=  ^  °  $a.G a($a.Fa(X  *)“,  $a.Fa(x)“)  °  $*GaW»)#  =  ^  °  $a.Ga($a.Fa(x) )“  °  $a.GaW>)# 
So,  in  particular, 

J"(^,(5>a.G(Fa)(x)(^a.Ga(^)^)))  =  (^  °  ^a,Ga(^a.Fa(x))B  °  ^l.Gafif)  fix)  =  XB  ^x) 

=  ±{XX)  , 

and  since  lifting  is  injective,  we  get  the  first  coherence  equation.  The  second  one  is 
analogous.  ■ 


A. 4  Invariant  relations  over  recursive  types 

We  now  want  to  show  that  certain  principles  for  constructing  relations  over  recursive 
types  are  valid;  specifically,  that  a  class  of  well-behaved  relational  actions  allows  us  to 
solve  “recursive  relation  equations” .  The  following  presents  only  the  specific  results  we 
need  for  the  proofs  in  Chapter  4:  for  a  general  treatment  of  the  subject,  see  [Pit99] . 

Throughout  this  section,  let  us  assume  a  fixed  relational  correspondence  between 
predomain  interpretations  C  of  L  and  £  of  L' ,  with  a  computation-extension  of  relations. 
In  keeping  with  the  general  convention  in  this  appendix,  we  also  write  ±R  for  relation- 
lifting.  We  first  characterize  a  particularly  well-behaved  way  of  constructing  admissible 
relations: 

Definition  A.  15  Let  F  and  F'  be  type  constructors.  A  (mixed)  relational  action  T  for 
F  and  F'  assigns  to  every  pair  of  relations  R  £  ARel(a~,  a’~)  and  R+  €  ARel(a+,  a'+ ) 
a  relation  F(R~ ,  R+ )  £  ARel(<f>a.^a(a:~,  a+),  Qa.F’a,{a'  , a/+)).  We  say  that  this  action  is 
admissible  if  it  satisfies: 

fix  Rf  x' .  f~x  fiRf)  f'x')  A  (fix  Rf  x'.  f+x  fiRf)  f'+  x') 

^VyF(Rf,Rf)  y’.$a.Fa(f-J+)y  fiF(R(,Rf))  $a.F,a(/'-,  f’+)y’ 

Likewise,  for  computation-type  constructors  G  and  G1 ,  a  relational  action  is  called 
computation- admissible  if  it  maps  R  £  ARel(a:~,  a'~)  and  R+  £  ARel(»+,  a:/+)  to  a 
relation  Q(R~,R+)  £  CARel(\l/a.Ga(aA,  o+),  i^a.G'a{pl  ,  cd+))  such  that 

(fix  R(  x' .  f~  x  fiRf)  f'x')  A  fix  Rf  x'.  f+x  fiRf)  f'+  x') 
^\/yg(R2,Ri)y’.A>a.Ga(f-J+)yG(R(\Rl)  'fa.G'a(f'-J,+)y' 

It  is  easy  to  see  from  the  definition  of  ^a.p{f^,f+)  that  any  computation-admissible 
action  is  also  admissible.  Moreover,  we  have  a  number  of  standard  ways  of  constructing 
(computation-) admissible  relational  actions: 

Lemma  A.  16  The  following  relational  actions  are  all  admissible  (and  computation- 
admissible  where  noted): 

1.  F{R-,  R+)=R+  for  Fa  =  F'a  =  a. 
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2.  F(R~ ,  R+ )  =  Rq  for  Fa  =  a0  and  F' a  =  a'0,  where  a0  and  a'0  do  not  depend  on  a, 
and  R0  G  ARel  (a0 ,  o/0 )  A  an  arbitrary  admissible  relation.  T  is  also  computation- 
admissible  if  Rq  is. 

3.  F{R~ ,  R+)  =  F\(R.  ,  R+)  xr  F2{R~,  R+ )  for  Fa  =  F\  a  x  F2a  and  F'a  =  F[  a  x  F^a, 
where  F\  is  admissible  for  F\  and  F[,  and  F2  is  admissible  for  F2  and  F^.  F  is 
also  computation- admissible  if  both  F\  and  F2  are- 

4-  F(R~,R+)  =  FfR~ ,  R+)  +r  F2{RA  R+)  for  Fa  =  Fia  +  F2a  and  F'a  =  F{a  +  F2a, 
where  F\  is  admissible  for  Fi  and  F[,  and  F2  is  admissible  for  F2  and  F 

5.  F(R~,R+)  =  YjFjfR- ,  R+)  for  Fa  =  N7F,a  and  Fa  =  T.jF'a.  where  for  every 
i  G  I,  Fi  is  admissible  for  Fi  and  F[. 

6.  Q{R-,R+)  =  F{R+,R-)^rG1{R-,R+)  for  Ga  =  Fa^Gfia  and  G' a  =  F'a^G^a, 
where  F  is  admissible  for  F  and  F1 ,  and  Gi  is  computation- admissible  for  G i  and 
G\ .  Q  is  also  computation- admissible. 

7.  G{R~,R+ )  =  °F(R~,  R+)  for  Ga  =  “(Fa)  and  G'a  =  “(F'a),  where  F  is  admissible 
for  F  and  F' .  G  is  also  computation- admissible. 

8.  F(R~,R+)  =  f) j£j  Fj(R~ ,  R+)  for  any  F  and  F' ,  when  for  every  j  G  J,  Fj  is 
admissible  for  F  and  F' .  F  is  also  computation- admissible  if  each  Fj  is. 

Proof.  Simple  verification  in  all  cases.  For  example,  and  since  it  is  somewhat  non¬ 
standard,  let  us  go  through  the  details  of  (7),  i.e. ,  °F(R~,R+).  First,  we  note  that  for 
any  computation-extension  of  relations  we  have  that  if  Va  R\  a',  fa  (°R2)  fa'  then 

Vm  (7F1)  m' .  let7  x  X=  rn  in  f  x  (°R2)  let7  x!  X=  rn'  in  f'x' 

(Note  that  this  is  simply  condition  (0)  of  a  monad  relation  from  Definition  3.26  in  the  case 
where  the  ambient  effect  is  partiality,  and  °R2  is  taken  as  the  'R2  of  the  definition.)  This 
holds  because  °R2  is  by  definition  computation-admissible  and  hence  pointed.  Thus,  since 
rn  (7i?i)  m!  means  that  either  both  rn  and  m'  are  _L,  or  both  are  liftings  of  Afi-related 
elements,  we  get  the  required  relationship  in  either  case. 

We  can  now  verify  admissibility  of  the  action  (R~,R+)  \-^-°F(R~ ,  R+)  for  the  type 
constructors  Ga  =  “(Fa)  and  G'a  =  “(F'a)  when  F  is  an  admissible  action  for  F  and  F' . 
Let  the  Rs  and  / s  be  as  in  Definition  A.  15;  we  must  then  show: 

Vy  l/.*a :Mf-,f+)v  (V(i?r,i?+))  *,.W/G r*)y' 

So  assume  y  (°F(Rf ,  Rf))  y' .  Expanding  H/a.°Fa(/A  f+)  according  to  Definition  A.l,  we 
must  then  establish  that 

let“  x  <t=  y  in  let7  r  -<=  <ha.Fa(/_,  f+)x  in  °r  {°F(Rf ,  Rf))  let“  x'  <t=  y'  in  •  •  • 

By  property  (2)  of  relation-extension  and  the  assumption  on  y  and  y',  it  suffices  to  show 
that 
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\fxR{R2,R+)  x'. 

let1-  r^$a.Fa  (/%/+)*  in  °r  (°R{Rf,Rf))  let1  r'  <=  $a.F'a(/'_,  f'+)  x'  in  V 
Let  x  T (R2 ,  R\ )  x'  be  given.  By  assumption  on  T .  we  then  have  that 

‘I’a.Fai/  ..E)X  (  IFU^.RO)  <I>;,/va(.r  ./'  )/ 

And  hence,  by  the  observation  at  the  beginning  of  the  proof,  it  suffices  to  show 

\/rR(R^Rl)r'Ar(°R(R^Rl))  V 

which  follows  immediately  from  property  (1)  of  relation  extension.  ■ 


We  also  have  the  following  principle  for  constructing  new  computation-admissible  actions 
from  old  ones: 

Lemma  A. 17  Let  G\  be  a  computation- admissible  relational  action  for  G\  and  G\ ,  and 
let  G  and  G'  be  another  pair  of  computation-type  constructors.  Further  let  h  be  a  rigid 
natural  transformation  from  G  to  G\ ,  i.e.,  satisfying 

-.A  )*)  =  *a.Gla(/A/+)(M 

and  analogously  for  h! .  Then  the  relational  action  Q  for  G  and  G'  defined  by 

x  G{R,R+)  x'  -<=>  hx  Gx{R ,R+)  h'  x' 
is  computation-admissible. 

Proof.  We  first  note  that  Q(R~,R+)  is  a  computation-admissible  relation  by  assump¬ 
tion  on  Gx  and  rigidity  of  h  and  h' .  Further,  let  the  Rs  and  / s  be  as  in  Definition  A.  15: 
we  must  show  that 

yyg(Rf,Rt)  y'^,.cMA.f+)yQ(Rf,Ri)  f,+  )y' 


I.e.,  that 

\/y1y,.hyg1(R2lRi)  h' y'  =>  h  (^>a.Ga(/%/+)  y)  Gi  {Rf,R%)  h'  (tfaW/'A  f'+)  y') 

Now,  by  assumption  on  h  and  h',  this  is  equivalent  to 

Vy,  y.  hy  Gx(R2 ,  Rf)  h'y'  =»  *a.Gla(.T,  f+)  ( hy )  Gi{Rf,Rj)  *a.G'a  (/'-,/'+)  (h'y') 

and  that  follows  form  the  assumption  that  Q i  was  admissible  (taking  y  and  y'  in  the 
definition  of  admissibility  to  be  the  hy  and  h' y'  above).  ■ 

From  this,  we  get  admissibility  of  the  action  relating  ambient  computations  to  their 
continuation-passing  counterparts: 
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Lemma  A.  18  Let  7  be  a  type  of  L' ,  and  for  any  R  E  ARel(o',  a!)  let  the  relation  °R  E 
CARel(°o;,  (a'  — >■  “7)  — >■  “7)  6e  giwen  by: 

m  (°R)  u 

Veto  type/,,  O  E  ARel(ct0, 7).  AA:tW  let°  x  7=  m  in  Auc  ((R  — >■  °0)  —t  °0)  u 

Further,  let  F  and  F'  be  type  constructors,  with  an  admissible  relational  action  T .  Then 
the  relational  action  Q  given  by 

g{R-,R+)  ="R{R-,R+) 

is  computation- admissible  for  G a  =  "(Fa)  and  G' a  =  (F1  a  — >■  “7)  — >■  ”7. 

Proof.  First  note  that  for  any  ct0  and  O  E  ARel(a0,7),  the  action  Qf  given  by 

Q?{R-,R+)  =  {R{R-,R+)  -V  °0)  -V  °0 

is  computation-admissible  for  Gf° a  =  (F a  — >■  °ct0)  — >■  °cto  and  G'  by  Lemma  A. 16(2, 6). 

Let  h  =  A m.  Xk.  let°  x  <=  m  in  kx.  This  mapping  is  a  natural  transformation  between 
the  functors  derived  from  G  and  Gf°: 

M'I'a.  / ;,(/  :«  /  '  )'")  =  h(let°  r^m  in  let1  y  <=  $a.Fa(/A  /+)  r  in  °y) 

=  AA\let°  a:  <=  (let°  r^m  in  let1  y  <=  ^a.Fa(/A /+)r  in  °y)  in  kx 
=  AA;.let°  r  <=  m  in  let1  y  <=  <&a.Fa(f  ,  /+)r  in  ky 

=  Xk.(hm)(Xr.let±  y  <=  $a ,.Fa(f~ ,  f+)  r  in  ky)  =  Xk.  (hm)  (’La.Fa->-°a0(/+j  f  )k) 

=  A  A  let1  y  ^  1(Ta.Fa^»Qo(/+, /^)  A:)  in  (hm)  y  =  ^a.(Fa^‘a0)^’a0U^  J+)  ihm) 

(using  that  Ta.°ao(/~,  f+)  =  id-Q0  by  Lemma  A. 2(1),  because  a  cannot  appear  free  in  ct0)- 
Thus,  taking  h!  as  the  identity  in  Lemma  A. 17,  we  get  that  the  action  given  by  Q° , 

m  (Q°(R~  ,R+))  u  =  AA:.let°  x  <=  m  in  ka  (Q°(R~,R+))  u 

is  computation-admissible  for  G  and  G' .  And  finally,  since  Q(R~,R+)  is  the  intersection 
of  all  Q°(R-,R+),  we  get  the  result  by  Lemma  A. 16(8).  ■ 

We  can  now  state  the  main  result  motivating  the  definition  of  admissible  actions: 

Theorem  A.  19  Let  T  be  an  admissible  relational  action  for  type  constructors  F  and  F' . 
Then  there  exists  an  invariant  relation  for  T ,  i.e.,  a  relation  A  E  ARel(//a.  Fa,  //a.  F'a) 
such  that  a  A  a1  <T7>  unrolla.^aa  J-(A,  A)  ur\roWa,F'aa' . 

Proof.  (The  proof  technique  is  due  to  Pitts  and  can  essentially  be  found  in  [Pit99] . 
However,  since  we  are  working  with  binary  relations  instead  of  unary  ones,  and  a  few 
details  are  slightly  more  involved  for  predomains  than  for  domains,  it  seems  worth  spelling 
out  the  construction.) 

As  usual,  we  abbreviate  roll  as  f>  and  unroll  as  if. 

We  first  note  that  a  functorial  action  on  relations  preserves  inclusions.  For  let  Rf  C 
Rf  and  Rf  C  Rf .  Take  /“  =  f+  =  Aa.  1a  and  /,_  =  fl+  =  Xa'Aa1.  Then  clearly 
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f  (R1  ->■  ±R2  )  /'  and  /+  {Rf  ->■  xi#)  /'+.  Hence  for  any  y  F{R2,Rf)  y,  we  get 
from  Lemma  A. 2 (3)  that 

x V  =  $a.Fa (Aa.xa,  A afa)y  ipLJ:{Rp,  Rf))  Ta.F'a(Aa'.  xa',  Aa'.  V)  ?/  =  V- 

Moreover,  we  easily  see  that  W  (xif)  Ac'  iff  :r  F  ;c'  (by  definition  of  relation-lifting  specific¬ 
ally,  not  true  for  computation-extension  of  relations  in  general),  so  we  get  y  F(Rp,  R2  )  y' , 
i.e. ,  F(Rp,Rf)  C  F(Rp,  Rf).  In  other  words,  T  is  monotone  in  its  second  argument 
and  antimonotone  in  the  first  one. 

Let  R  and  R+  be  arbitrary  relations  in  ARel(//a.  Fa,  //a.  F'a),  and  define  the  rela¬ 
tions  RA,  R+  G  ARel(/v,a.  F a,  ya.  F' a)  by 

a  RA  a'  tpa  F(R+,  R)  fa'  and  a  R±  a'  if  a  F(R~,  R+)  if)' a’ . 

We  can  then  define  an  operator  0,  mapping  (R~,R+)  to  (RA,RA),  antimonotone  in 
the  first  position  and  monotone  in  the  second.  Further,  the  set  of  admissible  relations 
between  two  types  is  closed  under  arbitrary  intersection,  so  ARel(yua.  Fa,  //a.  F'a)op  x 
ARel(yua,  Fa,  ya.  F' a)  forms  a  complete  lattice.  Hence,  by  the  Knaster-Tarski  fixed-point 
theorem,  0  has  a  least  fixed  point  (A~,A+),  with  A~,A+  G  ARel(/ra.  Fa,  ya.  F'a) 
satisfying 

a  A~  a'  <G=>  t/a  F(A' .  A  )  ip' a!  and  a  A+  a'  t/a  IF  (A  .A)  ip' a!  . 

Moreover,  (A+,  A-)  is  clearly  also  a  fixed  point  of  0,  and  so  must  be  greater  than  the 
least  one,  giving  (for  both  components)  the  inclusion  A+  C  A-. 

It  thus  remains  to  show  containment  in  the  other  direction.  Consider  the  relation 
V  G  CARel(/v,a.  Fa  — >■  ±ya.  Fa,  //a.  F'a  — >■  x/ja.  F'a)  determined  by 

h  V  h'  ^  Va  A-  a.  ha  (XA+)  h' a 

(V  is  computation-admissible  because  it  is  given  by  an  intersection  over  inverse  images 
(by  application,  which  is  rigid)  of  the  computation-admissible  XA+.)  Now  define  the 
functional  H  :  (ya.  Fa  — >■  x/ua.  Fa)  — >■  (ya.  F a  — >■  x ya.  Fa)  by: 

H  =  A/Ca  Fa^±,ta  Fa.  Aa'ia  Fa.letx  x  <=  <La.Fa(/i,  h)  (if  a)  in  ±((fx) 

and  analogously  for  If.  We  want  to  show  that  when  h  V  //'  then  also  If  h  V  //'  //'.  i.e., 
that 

Va  A-  a'.  letx  .r  -<=  <&a.Fa(/i,  h)  (Va)  in  x(Va;) 

(XA+)  letx  x'  <=  $a .F,a{ti,  h')  {ip' a')  in  J~((ft  x') 

This  follows  from  the  usual  properties  of  relation-extension,  the  equations  defining  A~ 
and  A+  above,  and  the  functorial  action  of  PF  (taking  =  f+  =  h,  f'~  =  f'+  =  h\ 
Rf  =  Rf  =  A-,  and  Rp  =  Rf  =  A+). 

Thus,  since  the  relation  V  was  computation-admissible,  we  get  by  fixed-point  induc¬ 
tion  (Lemma  3.19)  that  fixiV  V  fixF'.  And  because  fixF  =  Xxfx  by  the  minimal- 
invariant  property  (Corollary  A.8),  we  have 


Va  A  a'.  xa  (XA+)  xa' . 
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Finally,  by  the  same  argument  about  ±R  as  at  the  beginning  of  the  proof,  this  simplifies 
to  A~  C  A+,  completing  the  proof  that  we  can  take  A  =  A~  =  A+  as  the  invariant 
relation  for  T .  ■ 

From  this,  we  immediately  get  that  -  much  like  recursive  type  equations  -  a  large 
class  of  recursive  relation  equations  has  solutions: 

Corollary  A. 20  Let  F  and  F'  be  type  constructors,  and  let  *  be  a  formal  relation  con¬ 
structor,  built  out  of  (1)  the  standard  relational  actions  of  L\-type  constructors,  (2) 
constant  admissible  relations  (computation- admissible  for  computation-types),  and  (3) 
the  relation  constructor  °  (for  any  j);  so  that  *  maps  any  relation  R  E  ARel(a,  a')  to 
*R  E  ARel (Fa,  F'a'). 

Then  there  exists  a  relation  pR.  *R  E  ARel(//a.  F a,  pa,.  F'a)  such  that 

a(pR.'R)  a'  unrolla.^a  a*{pR.*R)  unrolla.F'afl/  • 

Proof.  By  induction  on  *,  using  Lemmas  A. 16  and  A. 18,  we  directly  obtain  an  admiss¬ 
ible  mixed  relational  action  F ,  such  that 

T{R,R)  =  * R 


By  Theorem  A.  19,  this  T  has  an  invariant  relation  A.  And  because  of  the  equation 
above,  we  can  simply  take  pR.  *R  to  be  A.  ■ 
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